CVS Administration

From OpenSSI

This is a work in progress and is by no means complete

NOTE: Should discuss how branches are synchronized using the MERGE-* tags.

NOTE: Emphasize that before merging a branch with newer base code, all recent OpenSSI/CI changes to that branch should first be synced to all other branches. Otherwise, the recent OpenSSI/CI changes are lost in the "noise" of the base changes.

The Trunk and "Common" Files

The trunk should only contain files that are common across all distro branches. Stated another way, if you do a checkout of the trunk into trunk_dir/ and a checkout of one of the distro branches into branch_dir/, the following command should not return anything:

   $ diff -rqxCVS trunk_dir branch_dir | grep '^Files.*differ'

This commonality is assured by aliasing the trunk files onto all distro branches. Whenever a new file is added to the trunk, it must be aliased to the distro branches with the following commands:

   $ cvs admin -n OPENSSI-DEBIAN:1 <filename>
   $ cvs admin -n OPENSSI-FC:1 <filename>
   $ cvs admin -n OPENSSI-SU:1 <filename>

Also, the merge tags must be aliased for the new file:

   $ cvs admin -n MERGE-DB-FC:1 <filename>
   $ cvs admin -n MERGE-FC-DB:1 <filename>
   $ cvs admin -n MERGE-SU-FC:1 <filename>
   $ cvs admin -n MERGE-FC-SU:1 <filename>

These merge tag aliases ensure that the file always looks like it's been synced between all distro branches, which it always is!

If any top-level subdirectory (e.g., ci/cluster-tools, openssi/openssi-tools) contains any files on the trunk, then all files it contains must also be on the trunk. For example, the following command should not return anything:

   $ diff -rqxCVS trunk_dir/openssi-tools branch_dir/openssi-tools

Without this requirement, it would be harder to keep track of which files should be common and which should not.

Importing Base Code

In the OpenSSI repository, pristine base code should be imported onto the proper vendor branch (there are several). This is done to facilitate building RPMs, and to provide convenient reference for generating a "diff" of what was changed for OpenSSI.

The import command used for the OpenSSI repository involves many options. As an example, the import command for the SuSE util-linux was:

   # cvs import -d -ko -I! -b 1.1.9 -m "Import of util-linux 2.12c-4 for SuSE" openssi/util-linux SUSE UTIL-LINUX-SU-2-12C-4

This example assumes that the CVSROOT environment variable has already been set for the OpenSSI repository.

IMPORTANT: The 'cvs import' command imports all files under the current working directory.

These various options tells CVS to:

• (-d) preserve the date stamps
• (-ko) preserve RCS expansion strings in the code (otherwise, diffing OpenSSI changes against the base can be very painful)
• (-I!) don't ignore any files under your current working directory (be sure there are no stale CVS directories lying around)
• (-b 1.1.9) vendor branch number, which must match the symbolic name below
• (-m ...) import message, which states the name of the package, its version number, and for which distro it's intended (unless its VANILLA source, such as kernel code from kernel.org)
• (openssi/util-linux) where in the repository to import the files under the current working directory
• (SUSE) vendor branch symbolic name, which must match the branch number above
• (UTIL-LINUX-SU-2-12C-4) revision name, consisting of package name (UTIL-LINUX), abbreviated distro name (SU), and version number (2-12C-4).

Unfortunately the import will leave junk lying around on the trunk which then has to be removed by hand. (it would be nice to use the -X option to import to mark the new files DEAD, but that doesn't work with SourceForge's version of CVS).

Note that the version number for the revision tag is all capital letters, with hyphens substituted for periods (2-12C-4, rather than 2.12c-4).

As emphasized above, each vendor branch number is associated with a symbolic branch name:

   1.1.1 -> VANILLA
   1.1.3 -> REDHAT
   1.1.5 -> DEBIAN
   1.1.7 -> FEDORA
   1.1.9 -> SUSE
   1.1.11 -> RHEL
   1.1.13 -> UBUNTU

The choice of vendor branch to use depends on where the base code came from. If it came directly from GNU or an open-source project, such as kernel.org, then use the VANILLA branch and don't use the -X option. If the code came from a distribution vendor, use the appropriate vendor branch.

OpenSSI Documentation

There are fedora/, debian/, and redhat/ subdirectories for openssi/docs that contain documents tailored specifically to their respective distro. Files outside of these subdirectories are either distro-independent or contain information for all distros.

There is a need to occasionally sync between these subdirectories, so each subdirectory is marked with the tag listed next to it below:

   openssi/docs/fedora/  ->DOCS-DB-FC
   openssi/docs/fedora/  ->DOCS-SU-FC
   openssi/docs/debian/  ->DOCS-FC-DB
   openssi/docs/redhat/  ->DOCS-FC-SU

These tags work just like the merge tags, except they're used for syncing between subdirectories rather than between distro branches.