[cvsnt] Re: CVS Use case
grstarrett at cox.net
Fri Apr 22 03:30:23 BST 2005
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:
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:
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.
More information about the cvsnt