0

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?

Chas. Owens
  • 64,182
  • 22
  • 135
  • 226
  • I think your plan meets your requirements about as well as you can via CVS alone. Make sure you tag generously. – antlersoft Jun 16 '11 at 17:36

1 Answers1

0

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?

Community
  • 1
  • 1
mikerobi
  • 20,527
  • 5
  • 46
  • 42
  • Given that CVS is being forced on us by a political decision, I want to avoid a work around that makes it look like we are ignoring the authorities. That said, it might come down to this sort of solution. – Chas. Owens Jun 16 '11 at 17:42