CVS Branching

We should create a release branch rel-2-2-dev before the feature freeze, and do the freeze on that branch instead of in HEAD. We can upgrade hosted.webwork and math.webwork to this branch at the same time, to get some serious testing done. If other developers happen to be working on big features at the time, they can continue to do so in HEAD.

It would look like this:

     |<-- development -->|<---------- development ------------------>
HEAD --------------------+------------------------------------------>
                         | /\    /\    /\    /\
                         | ||    ||    ||    ||  bug fixes forward-
                         | ||    ||    ||    ||  and back-ported
                         | \/    \/    \/    \/
    rel-2-2-dev (branch) *--------------+--------------+------------>
    (math.webwork and    |<-- freeze -->|<-- freeze -->|
    hosted.webwork run   |  (bugfixes)  |  (bugfixes)  |
    this branch)        /              /              /
                       /              /              /
            (not a release)      rel-2-2-0      rel-2-2-1

Here's how I initially create a new release branch:

# branch the current HEAD as rel-2-2-dev
cvs -d /webwork/cvs/system rtag -b rel-2-2-dev webwork2 pg
# tag the current rel-2-2-dev as rel-2-2-start, to mark the start of the branch
cvs -d /webwork/cvs/system rtag -r rel-2-2-dev rel-2-2-start webwork2 pg

(I'm assuming that no changes have been made to the rel-2-2-dev branch between the two commands. Maybe we could tag HEAD as rel-2-2-start and then branch from that tag instead. That way, we'd have a fixed tag to branch off of. Would that make any difference?)

Developers who wish to help prepare the release and fix bugs should check out a new working copy on the rel-2-2-dev branch. (Note the custom checkout dir names.)

cvs -d /webwork/cvs/system co -r rel-2-2-dev -d webwork2_rel-2-2-dev webwork2
cvs -d /webwork/cvs/system co -r rel-2-2-dev -d pg_rel-2-2-dev pg

As bugs are fixed in this branch, they should be forward-ported into HEAD. My theory is that it's easier to forward port bugfixes from a branch that contains only bugfixes than it is to tease bugfixes out of an unstable and rapidly-changing HEAD and backport them. However, in reality it turns out that most bugs get fixed in HEAD and then need to be backported into a release branch. I usually end up doing this by looking at the commit logs that have been emailed to me and feeding the diffs into the release branch.

Here's a recipe for committing a change to two branches easily. If your current working copy is on the rel-2-2-dev branch:

cd webwork2
<tweak file "foo">
cvs commit foo                        # check into rel-2-2-dev
<CVS says, checked in "foo" version 1.10.2.5>
cvs up -A foo                         # switch to HEAD
cvs up -j 1.10.2.4 -j 1.10.2.5 foo    # merge the change
<deal with conflicts in "foo", if any>
cvs commit foo                        # check into HEAD
cvs up -r rel-2-2-dev foo             # go back to rel-2-2-dev

This gets slightly more complex for multiple file commits, since you need a separate merge line for each file:

cd webwork2
<tweak files "foo" and "bar">
cvs commit foo bar                    # check into rel-2-2-dev
<CVS says, checked in "foo" version 1.10.2.5 and "bar" version 1.5.2.4>
cvs up -A foo bar                     # switch to HEAD
cvs up -j 1.10.2.4 -j 1.10.2.5 foo    # merge the change for "foo"
cvs up -j 1.5.2.3 -j 1.5.2.4 bar      # merge the change for "bar"
<deal with conflicts in both files, if any>
cvs commit foo bar                    # check into HEAD
cvs up -r rel-2-2-dev foo bar         # go back to rel-2-2-dev

But most bug fixes should be pretty localized, so I think it'll be manageable. If it turns out to be onerous, I can write or find a script to do it automatically.

Later on, when there are Zarro Boogs, we'll tag the current rel-2-2-dev as rel-2-2-0, make tarballs of it, and release them.