CVS – Developing on a Branch

I’ve been reading up on branching strategies over at Stackoverflow. Over and over I’m hearing about developing on the trunk (ie. main). I’ve used CVS for years and I don’t really understand or agree with this strategy.

I’ve been reading up on branching strategies over at Stackoverflow. Over and over I’m hearing about developing on the trunk  (ie. main). I’ve used CVS for years and I don’t really understand or agree with this strategy.

A few links:

At work, main exists only for branching and branches are only ever one level deep. This is to avoid losing yourself in deep branch nests. Main is kept in sync with the current production branch or the next known branch for which it is known it will become production.

A new project would immediately branch. Once it’s up and running and in production, it’s sync’d with main. New releases are branched off of main. Whenever a new release branch is needed, production or production-to-be is merged to main and main is branched.

This enables a system of merging that is only ever upwards. At some point branch A may be merging to B and C, but once B is known to be the next production branch, merging becomes A to B to C.

While writing this, I’ve been reading the CVS wikipedia article and the Trunk (Software) wikipedia article, and I begin to see a little bit of the pros and cons of developing on the trunk.

But what about parallel development?

Leave a Reply