Question

I have been using distributed version control systems for the last few years, but now I am going to have to use CVS. The process I want is something like:

1. Each bug/feature is given a ticket
   in a ticketing system
2. A developer is assigned to a
   bug/feature (if necessary a ticket
   will be broken into smaller tickets
   so that the developer to ticket
   relationship is one-to-one)
3. The developer makes changes and associates them with the ticket
4. At regular points in time a set of
   tickets are chosen for a release
   candidate The release candidate will
   be tested
5. A release is built using a subset of
   the tickets from the candidate
6. and the cycle starts again

My current, naïve plan is to

1. put each ticket in its own branch off of the trunk
2. create a branch for each release candidate
3. merge the ticket branches into the release candidate
4. when a release candidate is considered good enough merge it into the trunk

I have forgotten everything I used to know about CVS, but I have a gut feeling that tells me this is going to be a mistake. What performance or other types of problems am I going to run into? Is there a better way to selectively create builds based on a subset of the work done during a given period?

Answer 1

You could locally use a distributed version control system, and publish to CVS when a feature is ready for release.

See this question: How to export revision history from mercurial or git to cvs?