Practical way to commit changes in source control to multiple branches

Question

A common scenario when using source control is to have a development branch along with versioned release branches. We use CVS, with HEAD as the development branch, and a branch named e.g. release-6-2 for the current release of a product.

Development of new features go into the development branch only, but bug fixes sometimes have to be checked into both the development branch and the current release branch. This can get quite tedious at times, so I am looking for practical ways to accomplish this.

When a file to be commited is in synch on the two branches, I am in particular looking for a quick "commit to these branches" solution.

(We use CVS as our source control system, so any CVS-specific answers are nice. However, it is also interesting to see whether other source control systems can offer a better way. On the client side we use Eclipse, so Eclipse solutions are good. But if you have a non-Eclipse solution, that is fine too.)

Subtile

Answer 1

Apply your fix to the oldest release branch required. Then merge the change to the next release branch and so on until you merge from the last release branch to the HEAD.

Say the oldest version of your product is 1.0 and you also have 1.1 and 1.5 releases. New features for the next release are being added to the HEAD. If a bug is found in 1.0, you apply the fix to the 1.0 branch. Merge from 1.0 to the 1.1 branch. Merge from 1.1 to the 1.5 branch, and finally merge from the 1.5 branch to the HEAD.

Merging from branch to branch is better than applying the fix manually to each branch.

With CVS you have to mannually keep track of what versions are merged, so that you do not include the same revisions when you do your next merge.

If you change to use Subversion, merging from branch to branch is easier. Eclipse's subversion tool will keep track of what revisions you have previously merged, greatly simplifying the task of doing repeated merges between two branches.

Changing to Subversion from CVS is easy(ish). You won't be the first to have made such a move.

Blueing

Answer 2

Like awalshe said, it's better to merge between branches. To cherry-pick a merge, the method described in Pragmatic Version Control using CVS is very good:

In the branch - tag (PRE_FOO) before the change, make the changes and commit, tag after the change (POST_FOO). Then, in trunk, merge using the tags:

cvs up -j PRE_FOO -j POST_FOO

Merging between branches is much easier and safer in SVN, and it's trivial to convert your entire CVS history to SVN - see cvs2svn. You should use either SVN 1.5, or - with earlier SVN versions - svnmerge.

Firebug