info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs "grouping" feature


From: Todd Denniston
Subject: Re: cvs "grouping" feature
Date: Fri, 02 Sep 2005 08:04:07 -0500

"Brouwer, Marcel" wrote:
> 
> Hi,
> I can't follow the complete discussion. 
> But if I'm right, there are some requests
> for functionality to support 'functional' 
> grouping the way I described before?!
> 
> If it's not here at the moment,what should be the best way to handle my 
> problem?
> >We are working with software releases which will 
> >be released at a certain point in time. And it is 
> >not clear
> >if al change request will be in it. (Some not 
> >finished jet, not passed acceptance test, or QC)
> >But also to propagate some change requests from 
> >development to test before the complete release will
> >be.
> 
> I saw in a newsgroup someone who handled this by: 
> Every developer had to put the change request number 
> in the commit info every time they commit.
> By using some fancy scripting he can determine which 
> files belong to each other.
> Than at delivery time for the release they make a 
> manual 'build' by tagging al files in changerequest 
> which where passed test/QC etc.
> 
> I think this is error prone and time-consuming. 
> There should be a better way.!!!

time-consuming: not really, 1) at least with our development the developer
should be giving useful comments when committing, anyway so all we are
asking for is one more piece of data that the developer should already know
any way, because 2) the developer should know why they are working on the
code (bug number or development order).

error prone: only mildly if your developers are any good, and your message
validator(s) can help them by double checking the number given against a
database (or other data store) relating open numbers and developers.


something that can help this and make a more "functional commit id" is have
the developer(s) work on branches and when they get the code functionally
complete then do a merge to the trunk (or main working branch), this will
make the commit appear as a functional change. 

The other option I can think of is a bad one, have the developers only do
commits when they have functionally complete and QC'ed changes.

I have not seen described another version control system (VCS) which does
what I think you have described, because I believe the VCS would have to
have an oracle program[1] to decide when a functional change was done and
tag that.

The method of having the developers put in appropriate data in the commit
message (with cvs) is a way that you could give enough information to a
program, with out an Oracle[2,1], so that it could then follow the rest of
the process and do the tagging with out necessarily involving more humans
than the developer doing the commit.


[1] 
http://www.everything2.com/index.pl?node_id=1498591&lastnode_id=124
http://en.wikipedia.org/wiki/Oracle_machine

[2]
http://www.catb.org/~esr/jargon/html/O/Oracle--the.html
http://en.wikipedia.org/wiki/Oracle

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]