[cvsnt] Re: CVS Use case

[Glen Starrett]

Matt Schuckmann wrote:
> One of biggest problems I have is how to accomplish requirement 1 in CVS.
> Initially tags seem ideal but then not so much as they are geared more
> towards project wide application and not individual files.

Tags will work for either.  If you really want to know the state of the 
project in which the developer was testing, then he should tag the 
entire project so that snapshot will be known.

> Branches for each task seem like a good fit except when you get into it you
> run into trouble with the second part of requirement 4, you end up with the
> potential of creating lots of extra revisions in files that aren't related
> to the Task, not to mention the shear number of tags required for a project
> of 8000 files.

Are you talking about the recommendation on tagging the branchpoint then 
each mergepoint (e.g. in the Cederqvist book)?  That isn't necessary 
with a CVSNT server, see:

http://www.cvsnt.org/wiki/MergePoint

IMHO, branching is the absolutely BEST way to do what you're talking 
about.  It is isolated and yet you can still pick up the latest updates. 
  You can decide from a number of strategies, see:

http://cvsbook.red-bean.com/cvsbook.html#Going%20Out%20On%20A%20Limb%20(How%20To%20Work%20With%20Branches%20And%20Survive)

That is the Cederqvist book, chapter "Going Out On A Limb (How To Work 
With Branches And Survive)"

Regarding item 5:  A possible scenario would be to have the developer 
work out on a branch.  Before they are ready for final review of the 
patch they would update from HEAD and tested themselves (they could have 
done so several times before without a problem).  When they are ready, 
they can create a diff of their branch to HEAD to get the net changes 
for that task.  Then the release coordinator can do the merging into 
HEAD (assuming you will be locking down HEAD for normal devs).


Lots of people run in ways very similar to what you have described. 
CVSNT makes it fairly painless once you get a process in place and 
explain it to your developers.


-- 
Glen Starrett