Populating a Test Release

Once the test release is created, the user needs to populate it with the particular packages he wishes to modify via the addpkg command. Let's say that header files in a second package depend on the package the user wants to modify. The user will want to build the libraries in the second package, but not modify the code. He can add the second package to the test release via the lnkpkg command.

When adding packages to the test release, an important consideration is which particular version to add. See Appendix  A for more details on cvs versioning. By default, it will check out of CVS the version of <package> that was used to make the <base-release>. It is a version that is guaranteed to work with <base-release>; however, it may not be the head version of the package. Developers will always want to use the head version when using the development release. The developer should be aware that the head version is not guaranteed to work with the <base-release>. The user can optionally specify to check out either the head version or a specific tagged version on the addpkg command line. One must be careful when committing changes to a version that is not the head or branched versions may be created, see Appendix  A.

For Example:

• cd <testrel>
  For example, in Figs. 3 and  4, the user typed cd ~foo.
• addpkg [-h] <package> [<tag>]
  This checks out the package from CVS to create the package sub-directory and its contents. For example, in Figs. 3 and  4, the user typed addpkg pkgB. The -h option is almost always used and indicates to check out the head version is CVS. If this option is NOT used, then the developer may want to consider using the command cvs update -A before commiting the package back into the repository or else CVS thinks you are trying to commit to a new branch and complains. ¹²

  If <tag> is present, addpkg does a cvs checkout -r<tag> package. In Figs. 3 and  4, the user typed addpkg pkgB to create the sub-directory pkgB and fill pkgB with sub-directories and code from CVS. addpkg also creates a soft link between the test release include area and the newly created package include area. For example, in Figs. 3 and  4, addpkg created a symbolic link ~foo/test/include/pkgB/ which points to ~foo/test/pkgB/include/.

• lnkpkg <package>
  This commands adds a package to your test release, but for compiling and linking purposes only. The developer will not modify the code in this package. You can figure out which packages you need to link to by running the SoftRelTools script depend (see Section  4.12). In Fig. 4 there is a package, pkgA, which depends on include files in pkgB that user Foo will modify. However, Foo does not need to modify any of the code in pkgA, Foo only wants to modify pkgB. To allow Foo to rebuild the libraries for pkgA without checking out the code for pkgA, we have created symbolic links between the test release and the official packages area. The symbolic link ~foo/test/pkgA/ points to $SRT_DIST/packages/pkgA/1.1/, and the symbolic link ~foo/test/include/pkgA/ points to $SRT_DIST/packages/pkgA/1.1/include/.

  You can figure out which packages you need to link to by running the SoftRelTools script depend (see Section  4.12).

• newpkg <package>
  How does one create a new package?

Once the user has a test release created in his development area, he can use the following commands in  3.4 to make modifications.