Exporting For Public Distribution

CVS is a good distribution mechanism for developers, but most users will obtain the software through a downloadable package instead. This package is generally not a CVS working copy – it's just a source tree that can be easily configured and compiled on the user's system.

However, CVS does offer a mechanism to help you create that package, namely the cvs export command. To export a project is just like checking out a working copy of the project, except that it checks out the project tree without any CVS administrative subdirectories. That is to say, you don't get a working copy, you just get a source tree that knows nothing about where it came from or what the CVS versions of its files are. Thus, the exported copy is just like what the public sees after it downloads and unpacks a distribution. Assuming the project is arranged to be directly compilable from a working copy (and it certainly should be!), then it will still be compilable from the exported copy.

The export command works like checkout, except that it requires a tag name or date. For example, here we tag the project with a release name, and then export based on that:

     floss$ pwd
     /home/jrandom/myproj
     floss$ cvs -q tag R_1_0
     T README.txt
     T hello.c
     T a-subdir/whatever.c
     T a-subdir/subsubdir/fish.c
     T b-subdir/random.c
     floss$ cd ..
     floss$ cvs -d /usr/local/newrepos -q export -r R_1_0 -d myproj-1.0 myproj
     U myproj-1.0/README.txt
     U myproj-1.0/hello.c
     U myproj-1.0/a-subdir/whatever.c
     U myproj-1.0/a-subdir/subsubdir/fish.c
     U myproj-1.0/b-subdir/random.c
     floss$ cd myproj-1.0
     floss$ ls
     README.txt  a-subdir  b-subdir  hello.c

Notice how, since the export command is not invoked from within a working copy, it's necessary to use the global -d option to tell CVS which repository to use. Also, in this particular example, we exported into an explicitly named directory (myproj-1.0) instead of defaulting to the project's name (myproj), since there was a working copy of that name already present. This situation is not uncommon.

After the exported copy is created, as in the above example, the following might be sufficient to complete the release, if the project is a simple one:

     floss$ tar cf myproj-1.0.tar myproj-1.0
     floss$ gzip --best myproj-1.0.tar
     floss$ ls
     myproj/   myproj-1.0/   myproj-1.0.tar.gz
     floss$ rm -rf myproj-1.0
     floss$ mv myproj-1.0.tar.gz /home/ftp/pub/myproj/

Of course, running all of these commands by hand is rare. More often, cvs export is called from within some script that handles all aspects of release and packaging process. Given that there are often several "test" releases leading up to each public release, it is desirable that the procedures for creating a releasable package be highly automated.