7.7. Version Control Actions: Checkin, Checkout, etc.
This command group offers the basic and most important functions of ComPact package version management. You can see a screenshot of the menu in Figure 7-13.
When applying version control commands, you should always have in mind the concept used by ComPact: All versions of all packages are kept in the central version control repository, from where developers checkout certain versions of packages into their local workspace. A developer always works on copies of the sources in his workspace, where he performs all changes and tests. If he is satisfied with the results of his work or wants to save a checkpoint of his efforts for later use, he commits the changes to the repository, thereby creating a new version of the package with a new symbolic name, also called a tag.
The checkout of a new version of a package into a package already existing in the local workspace is called update. An update command can also be issued when there are local modifications in the pacakge. ComPact will then merge the local modifications with the version specified as target of the update.
New versions can only be added at the head of the development trunk or at the tip of a release branch.
Committing changes to the repository . Commit transfers all local modifications of the package in your workspace to the central repository, and creates a unique version name (tag) for it. This tag has the form
devel_pkgname_major_minor_patch
-
For a major commit, the major version number is increased and the minor and patch level numbers are set to zero.
-
For a minor commit, the minor version number is increased and the patch level is set to zero.
-
For a patch commit, only the patch level is increased.
Releasing package versions . Release is similar to commit in that it makes all your local changes permanent in the central repository, but it creates a release version of the package, which is named by a tag of the following form:
release_pkgname_major_minor_patchFor major and minor release commits, new branches are created in the version tree of the package, which will grow with every patch commit. The numbering of release versions is completely distinct from the numbering of development versions.
You can only commmit or release your changes if the version your local workspace is based on is still at the head of the development trunk or a release branch. Otherwise you must update to the latest version first (ComPact will merge in the changes that have been added since your last checkout), resolve any conflicts that could not be automatically cleared (only if the same lines have been changed), and build and test your package again. Once you have committed the changes, all other developers have access to this version and may use the new version name in their update, checkout, merge, and diff commands.
Updating the checked-out version . Update checks out the version with the given name from the repository into your local workspace. The predefined name head refers to the version at the head of the development trunk, tip-of-branch refers to the latest version of the branch your package is checked out on, and last-release-branch refers to the latest version of the last release branch made. If there are any local modifications, they are merged with the updated version.
Creating new symbolic version names . Tag puts the given name on the version of the package that you have checked out last. If you have made local modifications, you must first commit them if the name shall refer to them. As ComPact automatically names every version you check in, there is really no need for this command, unless you want a special name to be used as a label on several packages.
Merging in changes from other branches . In addition to the implicit merging that occurs when updating to a new version and local changes have been made, there is the possibility to perform explicit merges from sets of changes located on other branches of the package history.
-
Branch Merge successively merges in changes made on a release branch into your local workspace. This is especially useful for the incorporation of bug fixes that have been made to a release, and must now be transfered to the development trunk.
-
Explicit Merge merges the differences between two arbitrary versions into your local workspace. You should only use this command if you are sure about what you are doing.