Patch Branches and Releases

Making a patch branch

Split off a branch in CVS, e.g.:

> cvs tag -b -r release-4_2_1 release-4_2_1_patch

which creates a branch rooted at the tag "release-4_2_1" called "release-4_2_1_patch".

Adding updates to the Patch Branch

Changes which are reported on the problems pages should also be added to the patch branch. This is the procedure that I use:

1. Make a patch for the change on the main branch, e.g.:

       > cvs diff -c -r <old_revision> <file> > patch.diff
       

2. Switch the file over to the patch branch:

       > cvs update -r release-4_2_1_patch <file>
       

3. Apply the patch:

       > patch -i patch.diff
       

4. Check that the patching has worked.
5. Commit the change (with the same comment as in the main trunk):

       > cvs commit <file>
       

6. Switch back to the main trunk using

       > cvs update -A <file>
       

Tagging and Exporting Patch Releases

Use the same mechanism as for official releases, e.g.:

> cvs tag -r release-4_2_1_patch release-4_2_2

will tag the most up-to-date files in the branch with the tag "release-4_2_2". The CVS "export" command can then be used to make releases and so on.

Making Source Code Patches (Upgrades)

Use the rdiff command of CVS to make diffs suitable for use with Larry Wall's patch program:

> cvs rdiff -c -r release-4_2_1 -r release-4_2_2 ccp4 > ccp4-4.2.1-4.2.1.diff

The patch can be applied using patch as follows:

1. cd $CCP4
2. [ftp ccp4-4.2.1-4.2.1.diff to this directory]
3. patch -p1 -N -i ccp4-4.2.1-4.2.1.diff >& patch.log
4. ./config.status ; make [install]

"-p1" means strip one level of directory name from those in the patch file; "-N" means don't try to apply reverse patches.

[Back: FTP Server]