GNU Info

(cvsbook.info)Exporting For Public Distribution

---

Next: The Humble Guru Prev: Tracking Third-Party Sources (Vendor Branches) Up: Advanced CVS

---

Enter node , (file) or (file)node

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.