Pan branching in CVS ==================== Approach to branches -------------------- Typically there are two branches active in CVS: one for the main development (HEAD) and one for bugfixes against the latest stable release. Any bugs that are fixed for the latest stable release are commited on the bugfix branch and get merged back onto the main branch: +--------+ | 0.12.0 | +--------+ | \ | +----------+ | | Bugfixes | | | (0.12.1) | | +----------+ | | |<-----------+ Merge | +--------+ | HEAD | |(0.13.0)| +--------+ This approach allows us to build bugfix releases against previous releases, while doing major code changes for the next release. Naming strategy --------------- CVS tags have the following format: pan--- (eg: pan-0-12-0) CVS branches have the following format: pan---fix (eg: pan-0-12-fix) Creating branches in CVS ------------------------- For reference, each (stable) release is tagged in CVS. An example: $ cvs tag pan-0-12-0 When needed, we create a branch: $ cvs tag -b pan-0-12-fix This creates a bugfix branch for the 0.12.x releases while we work on 0.13.0. Main development ---------------- Main development continues on the main branch. No changes needed. Bugfix development ------------------ To checkout a source tree for bugfixes, we use the following command: $ cvs co -d pan-fix pan # checkout the source tree $ cvs update -r pan-0-12-fix # switch the tree to the bugfix branch Alternatively, this can be done in one command: $ cvs co -r pan-0-12-fix -d pan-fix pan Commiting changes on the fix branch is identical to the main branch. To merge any changes back to the main branch, we switch to the source tree on the main branch and run the following command: $ cvs update -j pan-0-12-fix This merges all changes on the branch back to HEAD. If the two branches have drifted apart too much, this may merge unwanted changes. In this case, specify the exact version you want to merge. For example: $ cvs update -j 1.548.2.10 articlelist.c This merges only the changes introduced in version 1.548.2.10 to HEAD. Note: it's generally easier to develop bugfixes on the fix branch and merging them to the main branch. Doing it the other way around can easily lead to the wrong changes being merged onto the fix branch (e.g. code changes related to new features that aren't implemented on the fix branch). Help, I'm lost ! ---------------- When in doubt, you can always check whether you're working on the main branch or a bugfux branch: $ cvs status ChangeLog =================================================================== File: ChangeLog Status: Up-to-date Working revision: 1.1369 Repository revision: 1.1369 /cvs/gnome/pan/ChangeLog,v Sticky Tag: pan-0-12-fix (branch: 1.1369.2) Sticky Date: (none) Sticky Options: (none) In this example, we're working on the fix branch (Sticky Tag states 'pan-0-12-fix'), although the file itself has not yet been branched (Working revision is 1.1369, which is the main branch). So, this file is identical to the one that's in release 0.12.0. To see what changes have been made on the different branches, you can use the following Bonsai queries: http://cvs.gnome.org/bonsai/cvsquery.cgi?branch=HEAD&file=/pan/&date=day http://cvs.gnome.org/bonsai/cvsquery.cgi?branch=pan-0-12-fix&file=/pan/&date=day The first query shows today's changes on the HEAD branch, the second shows today's changes on the pan-0-12-fix branch. References ---------- CVS Tags: http://www.loria.fr/~molli/cvs/doc/cvs_4.html#SEC47 CVS Branches: http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49