Merging CLAM development branch to the main branch

Previous situation

The CLAM CVS module has two significative branches:

• The main one in the main cvs trunk.
• The developement one on the cvs branch tagged as development-branch.

Supose that the last CLAM version was 0.4.3 and we are going to release 0.5.0. So it is suposed to be some tags from the previous release:

• CLAM-devel-0_4_3-rel points to the development-branch the last merge point from development
• CLAM-0_4_3-rel points to the main branch point where such release was done
• CLAM-stable-rel points to the same point but is suposed to move with a new stable release

Checking a sane previous release

Maybe the previous situation doesn't fit the sane environment described above. You should confirm it.

• Confirm that the main-trunk tip matches the last release tag by doing:
  $ cvs rdiff -r CLAM-0_4_3-rel -r HEAD CLAM | vim -R -
• Confirm that there is a CLAM-devel-0_4_3-rel tag on the development branch. Doing a cvs log on the ChangeLog.txt file and checking the revision associated with such tag should suffice.
• If the CLAM-devel-0_4_3-rel tag try maybe the last release manager forgot it, but you can place it on the last prerelease tag on devel, ie, CLAM-devel-0_4_3-pre6-rel when the 6 prerelease became the final release.
  $ cvs rtag -r CLAM-devel-0_4_3-pre6-rel CLAM-devel-0_4_3-rel CLAM

Preparing the files

Check on the development-branch that the versions numbers on the following files are updated for the coming release:

• ChangeLog.txt
• .doxygen.cfg

Freezing the development branch

• Ask the developers to commit any pending changes for the release and update the ChangeLog.txt file.
• Place the tag CLAM-devel-0_5_0-pre1-rel on the development branch:
  $ cvs rtag -Fa -r development-branch CLAM-devel-0_5_0-pre1-rel CLAM
• Place a shifting tag named CLAM-devel-0_5_0-rel over the previous tag:
  $ cvs rtag -Fa -r CLAM-devel-0_5_0-pre1-rel CLAM-devel-0_5_0-rel CLAM
• Do a clean checkout of the shifting tag on your sandboxes directory
  $ cvs checkout -d CLAM-devel-testing -r CLAM-devel-0_5_0-pre1-rel CLAM
• Pass the test on the CLAM-devel-testing sandbox.
• If tests don't pass then the next section is for you.

Fixing freeze bugs

Warning: changes on the CLAM-devel-pre1 sandbox can't be commited because it has a sticky tag on CLAM-devel-0_5_0-pre1-rel. If you find bugs you should fix them on your own development sandbox.

• Go to your normal development sandbox and do the fixes.
• Once they work you can tag again with a new pre number CLAM-devel-0_5_0-pre2-rel
  $ cvs rtag -Fa -r development-branch CLAM-devel-0_5_0-pre2-rel CLAM
• And then shift the shifting tag to the new one
  $ cvs rtag -Fa -r CLAM-devel-0_5_0-pre2-rel CLAM-devel-0_5_0-rel CLAM
• Then you can do an update on the testing sandbox and changed files will update:
  $ cd path/to/CLAM-devel-testing; cvs update
• Test and repeat (pre3, pre4...) until all works fine

Merging devel changes into main

• First of all warn CLAM MTG users (clam-mtg@iua.upf.es) about CLAM CVS being inconsistent that they should stick onto a stable release tag.
• Do a clean main trunk checkout named CLAM-main-testing:
  $ cvs checkout -d CLAM-main-testing CLAM
• Do the merge it self (you must be placed on the CLAM-main-testing sandbox root):
  $ cvs update -j CLAM-devel-0_4_3-rel -j CLAM-devel-0_5_0-rel
• Check for any conflict by doing:
  $ cvs -q update | grep ^C
• Check merge results on the CLAM-main-testing. A practical way on doing this is to choose three files so that:
  • one has been modified on development branch
  • one has been removed on development branch
  • one has been added on development branch
• Check those files that must be different on both branches:
  • .doxygen.cfg: The output path should point to a diferent directory on the web and the tittle should point out the branch.
  • README: Should point out which branch it is
• Commit the changes to main
• Tag the main branch with a main-pre tag
  $ cvs rtag -Fa CLAM-0_5_0-pre1-rel CLAM
• Do an rdiff between development and main prerel tags in order to identify unexpected differences
  $ cvs rdiff -r CLAM-0_5_0-pre1-rel -rCLAM-devel-0_5_0_pre3-rel CLAM
• If there are suspicious differences, then do a clean checkout on the CLAM-0_5_0-pre1-rel and do some testing the same way you did with devel.
• When all the tests pass you can place the release tag:
  $ cvs rtag -Fa -r CLAM-0_5_0-pre1-rel CLAM-0_5_0-rel CLAM
• And move the stable release tag to the previous one:
  $ cvs rtag -Fa -r CLAM-0_5_0-rel CLAM-stable-rel CLAM

Replacing full files instead merging changes

Sometimes a merge like the one above, is not safe when:

• after the last merge, there has been changes on the main branch, or
• on the last merge, some changes on the development branch were not merged.

Rationale

Why not moving a single tag in each branch?

Because errors on tagging and moving tags are very common and, when they happen, you lose any reference to that point. So we use fixed points and one sliding point.

Too much tags, how can i get ride of them?

pre-rel tags are useless. Once you have released you can remove them from the cvs by doing:
$ cvs rtag -da TheTagToBeRemoved CLAM

Why the -a option?

It is needed in order to cope with deleted and added files.

Why rtag and not tag?

rtag, tags also deleted files so you can do safest diffs and merges between tags with different files. tag only sees the files on the current sandbox. Moreover, you don't need to to checkout any sandbox to do an rtag.

tag is useful to move tags for concrete files but use it on your own, only on concrete files (not on directories) and only when the only have been modified (not removed nor added). You have been warned.

Why rdiff and not diff

diff cvs subcommand has similar problems that tag has. It does not work with files that are not checked out, so it gives problems working with tags.

So use diff only to diff the version of a concrete file you checked out and the same file on the repository.