Structuring packages in directory hierarchies and versioning are fundamentally orthogonal concepts. CVS does a good job of taking care of both, but lets you see only one snapshot of the file revisions at a time. However, it is natural that in a number of occasions you want to shuffle from one package version to another. For instance, consider the case where you find that you have checked out a buggy version of a package your own code depends on. You may want to roll back to a previous version, but once the bugs have been resolved, you will want to roll forward to bring the package up to the corrected version.
Since the structuring and versioning are orthogonal, there are inherent problems in combining these two views. In particular, it is not obvious how to design a directory hierarchy that would allow several versions of each package to exist in the same tree. The approach chosen by the release tools is that exactly one version of the sources is visible in the tree at any one time--basically what CVS naturally does. This implies that every release contains a full copy of the sources of all the packages in the release. The advantage of this is that the structure matches the CVS structure one to one. The disadvantages are increased disk space consumption and the difficulty of viewing multiple versions simultaneously. However, this is not as bad as it may sound initially. The disk space used by the sources is negligible compared to the space used by the object files, libraries and executable built from the sources, and it is not straightforward to save space with the binaries across releases. Moreover, one still has all the facilities provided by CVS. For instance, to analyse revision differences in a source file one can use the CVS diff or annotate commands. Browsing utilities such as Bonsai also make the task much easier. Granted, it still is more difficult than directly browsing files on a file system--but the tools also add value that exceeds that of just having several revisions of the files on the file system.
Another issue brought about by the combination of hierarchies and distributed package development was already discussed in [xref to FORMALPARA unsupported]. Namely, each hierarchy nesting level must be versioned separately. Take for instance a package C that contains other packages like X and Y. All three must have separate version identifiers. Quite obviously X and Y may develop rather independently, but consequently so does C. For instance, suppose X advances by three versions while Y remains unchanged. The C coordinator would then have to assign a new version identifier for the new combination of the nested package versions. The new C version need not and seldomly does have any correlation to the version numbers of the contained packages.
To avoid any confusion about which version numbers apply to which packages the release tools always attach the package name to the version tag. This results in packages having version tag sequences: not only do they have the tags of their own, but also all the version tags of the containing packages. For example, package A/M/X in offline release 1.3.7 might have a tag sequence offline-01-03-07, A-02-33-12, M-01-12-01 and X-00-20-08. Each of these would designate the exactly same version of X: X-00-20-08.
| [1] | It is possible to use tag instead of rtag but you should stick to the latter whenever you can. tag has some relatively surprising behaviour when branches are involved or if you have just edited the files. While the behaviour is well documented in the CVS manual, it just happens not to be very obvious even if you read the description several times. Usually you will have to screw yourself up at least a couple of times and read the manual a few more times to understand what it really said. |