[spambayes-dev] More CVS branch/tags questions

[Richie Hindle]

[Kenny]
> Fixes that apply to both the 1.0 and 1.1 releases
> need to be made on both the branch and the trunk (because the current
> state of those versions could be different at the time the fix is made).

No, definitely not!  Fixes made on the bugfix branch should be
batch-merged onto the head once in a while, using "cvs up -j".  If you
have a policy of manually fixing both places then inevitably you sometimes
forget.  If you do lots of manual merging and only then try to merge the
branches you get hundreds of conflicts.  By doing a periodic merge, you
keep the code roughly in step as far as bugfixes go - close enough that
cvs can do meaningful merges - and you fix conflicts when you get them.

The fact that the head and the bugfix branch differ is rarely a problem
when it comes to merging - if you get conflicts, you fix them.  The fix is
usually obvious, and only needs to applied once.

Here's how the system works over time:

Head: 1.1   1.2   1.3  1.4 ....... 1.9 ......... 1.20 ........ 1.30
                   |                ^             ^             ^
    bugfix branch  |                | merge 1     | merge2      | merge 3
 (eg. release_1_0) |                |             |             |
                    --> 1.3.1.1  1.3.2.3 ..... 1.3.2.9 ..... 1.3.2.20

So you start with the head, then at some point you take your bugfix
branch.  1.4 is a feature, 1.3.1.1 is a bugfix (the specific numbers don't
matter).  At some point you decide to merge the bugfix branch onto the
head.  Why?

 o People working on the head are frustrated by the bugs
 o It's been a long time and the branches are getting out of step
 o Someone wants to start a major piece of work and wants to branch off
   the head to do it, and they want the bugfixes in place on their branch

So you get CVS to apply all the edits that have been made on the bugfix
branch to the head: you take a head checkout and do "cvs up -j bugfix".
You get some conflicts where bugfixes have been made to code that's
changed on the head, and you fix them (this is less of a problem than you
might think, once the code has stopped migrating wholesale from place to
place as it can do in the early stages of a project).

The next time you're going to want to do this merge, you'll want to take
all the edits made on the bugfix branch between this merge and the time
you do the next merge, and apply them to the head.  So after this first
merge, you mark the point on the bugfix branch at which you did your merge
by tagging it: "cvs tag bugfix_to_head" in a bugfix checkout.  That will
apply the bugfix_to_head tag to 1.3.2.3 on the bugfix branch (again, you
don't care about the numbers in the real world because you're operating on
entire branches).

Then at some later date comes merge 2: take the edits between
bugfix_to_head and the current state of the bugfix branch and apply them
to the head.  In a head checkout, "cvs up -j bugfix_to_head -j bugfix".
Fix your conflicts, and in a bugfix checkout, move your marker tag to the
new position: "cvs tag -F bugfix_to_head".  That moves bugfix_to_head to
1.3.2.9, ready for merge 3 at some later date.

All this takes longer to explain than to just do.  8-)  In the long run it
guarantees that bugfixes don't get lost, and that people can consistently
use each branch for its intended purpose.  Bugfix releases are always made
from the bugfix branch, which eventually comes to an end when a new
feature release goes out - and a new bugfix branch is taken for that
release.

-- 
Richie Hindle
richie at entrian.com