Contributed by Jordan K. Hubbard <jkh@FreeBSD.org>.
There are various ways of using an Internet (or email) connection to stay up-to-date with any given area of the FreeBSD project sources, or all areas, depending on what interests you. The primary services we offer are Anonymous CVS, CVSup, and CTM.
Anonymous CVS and CVSup use the pull model of updating sources. In the case of CVSup the user (or a cron script) invokes the cvsup program, and it interacts with a cvsupd server somewhere to bring your files up to date. The updates you receive are up-to-the-minute and you get them when, and only when, you want them. You can easily restrict your updates to the specific files or directories that are of interest to you. Updates are generated on the fly by the server, according to what you have and what you want to have. Anonymous CVS is quite a bit more simplistic than CVSup in that it's just an extension to CVS which allows it to pull changes directly from a remote CVS repository. CVSup can do this far more efficiently, but Anonymous CVS is easier to use.
CTM, on the other hand, does not interactively compare the sources you have with those on the master archive or otherwise pull them across.. Instead, a script which identifies changes in files since its previous run is executed several times a day on the master CTM machine, any detected changes being compressed, stamped with a sequence-number and encoded for transmission over email (in printable ASCII only). Once received, these ``CTM deltas'' can then be handed to the ctm.rmail(1) utility which will automatically decode, verify and apply the changes to the user's copy of the sources. This process is far more efficient than CVSup, and places less strain on our server resources since it is a push rather than a pull model.
There are other trade-offs, of course. If you inadvertently wipe out portions of your archive, CVSup will detect and rebuild the damaged portions for you. CTM won't do this, and if you wipe some portion of your source tree out (and don't have it backed up) then you will have to start from scratch (from the most recent CVS ``base delta'') and rebuild it all with CTM or, with anoncvs, simply delete the bad bits and resync.
For more information on Anonymous CVS, CTM, and CVSup, please see one of the following sections:
Contributed by Jordan K. Hubbard <jkh@FreeBSD.org>
Anonymous CVS (or, as it is otherwise known, anoncvs) is a feature provided by the CVS utilities bundled with FreeBSD for synchronizing with a remote CVS repository. Among other things, it allows users of FreeBSD to perform, with no special privileges, read-only CVS operations against one of the FreeBSD project's official anoncvs servers. To use it, one simply sets the CVSROOT environment variable to point at the appropriate anoncvs server, provides the well-known password "anoncvs" with the cvs login command, and then uses the cvs(1) command to access it like any local repository.
While it can also be said that the CVSup and anoncvs services both perform essentially the same function, there are various trade-offs which can influence the user's choice of synchronization methods. In a nutshell, CVSup is much more efficient in its usage of network resources and is by far the most technically sophisticated of the two, but at a price. To use CVSup, a special client must first be installed and configured before any bits can be grabbed, and then only in the fairly large chunks which CVSup calls collections.
Anoncvs, by contrast, can be used to examine anything from an individual file to a specific program (like ls or grep) by referencing the CVS module name. Of course, anoncvs is also only good for read-only operations on the CVS repository, so if it's your intention to support local development in one repository shared with the FreeBSD project bits then CVSup is really your only option.
Configuring cvs(1) to use an Anonymous CVS repository is a simple matter of setting the CVSROOT environment variable to point to one of the FreeBSD project's anoncvs servers. At the time of this writing, the following servers are available:
USA: :pserver:anoncvs@anoncvs.freebsd.org:/home/ncvs (Use cvs login and enter the password "anoncvs" when prompted.)
Since CVS allows one to ``check out'' virtually any version of the FreeBSD sources that ever existed (or, in some cases, will exist :), you need to be familiar with the revision (-r) flag to cvs(1) and what some of the permissible values for it in the FreeBSD Project repository are.
There are two kinds of tags, revision tags and branch tags. A revision tag refers to a specific revision. Its meaning stays the same from day to day. A branch tag, on the other hand, refers to the latest revision on a given line of development, at any given time. Because a branch tag does not refer to a specific revision, it may mean something different tomorrow than it means today.
Here are the branch tags that users might be interested in:
Symbolic name for the main line, or FreeBSD-current. Also the default when no revision is specified.
The line of development for FreeBSD-3.x, also known as FreeBSD-stable. Not valid for the ports collection.
The line of development for FreeBSD-2.2.x, also known as 2.2-stable. This branch is mostly obsolete. Not valid for the ports collection.
The line of development for FreeBSD-2.1.x - this branch is largely obsolete. Not valid for the ports collection.
Here are the revision tags that users might be interested in:
FreeBSD-3.3. Not valid for the ports collection.
FreeBSD-3.2. Not valid for the ports collection.
FreeBSD-3.1. Not valid for the ports collection.
FreeBSD-3.0. Not valid for the ports collection.
FreeBSD-2.2.8. Not valid for the ports collection.
FreeBSD-2.2.7. Not valid for the ports collection.
FreeBSD-2.2.6. Not valid for the ports collection.
FreeBSD-2.2.5. Not valid for the ports collection.
FreeBSD-2.2.2. Not valid for the ports collection.
FreeBSD-2.2.1. Not valid for the ports collection.
FreeBSD-2.2.0. Not valid for the ports collection.
FreeBSD-2.1.7. Not valid for the ports collection.
FreeBSD-2.1.6.1. Not valid for the ports collection.
FreeBSD-2.1.6. Not valid for the ports collection.
FreeBSD-2.1.5. Not valid for the ports collection.
FreeBSD-2.1.0. Not valid for the ports collection.
When you specify a branch tag, you normally receive the latest versions of the files on that line of development. If you wish to receive some past version, you can do so by specifying a date with the -D date flag. See the cvs(1) man page for more details.
While it really is recommended that you read the manual page for cvs(1) thoroughly before doing anything, here are some quick examples which essentially show how to use Anonymous CVS:
Example 18-1. Checking out something from -current (ls(1)) and deleting it again:
% setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/home/ncvs
% cvs login
At the prompt, enter the password "anoncvs".
% cvs co ls
% cvs release -d ls
% cvs logout
Example 18-2. Checking out the version of ls(1) in the 2.2-stable branch:
% setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/home/ncvs
% cvs login
At the prompt, enter the password "anoncvs".
% cvs co -rRELENG_2_2 ls
% cvs release -d ls
% cvs logout
Example 18-3. Creating a list of changes (as unidiffs) to ls(1)
% setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/home/ncvs
% cvs login
At the prompt, enter the password "anoncvs".
% cvs rdiff -u -rRELENG_2_2_2_RELEASE -rRELENG_2_2_6_RELEASE ls
% cvs logout
Example 18-4. Finding out what other module names can be used:
% setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/home/ncvs
% cvs login
At the prompt, enter the password "anoncvs".
% cvs co modules
% more modules/modules
% cvs release -d modules
% cvs logout
The following additional resources may be helpful in learning CVS:
CVS Tutorial from Cal Poly.
Cyclic Software, commercial maintainers of CVS.
CVSWeb is the FreeBSD Project web interface for CVS.
Contributed by Poul-Henning Kamp <phk@FreeBSD.org>. Updated 19-October-1997.
CTM is a method for keeping a remote directory tree in sync with a central one. It has been developed for usage with FreeBSD's source trees, though other people may find it useful for other purposes as time goes by. Little, if any, documentation currently exists at this time on the process of creating deltas, so talk to Poul-Henning Kamp <phk@FreeBSD.org> for more information should you wish to use CTM for other things.
CTM will give you a local copy of the FreeBSD source trees. There are a number of ``flavors'' of the tree available. Whether you wish to track the entire cvs tree or just one of the branches, CTM can provide you the information. If you are an active developer on FreeBSD, but have lousy or non-existent TCP/IP connectivity, or simply wish to have the changes automatically sent to you, CTM was made for you. You will need to obtain up to three deltas per day for the most active branches. However, you should consider having them sent by automatic email. The sizes of the updates are always kept as small as possible. This is typically less than 5K, with an occasional (one in ten) being 10-50K and every now and then a biggie of 100K+ or more coming around.
You will also need to make yourself aware of the various caveats related to working directly from the development sources rather than a pre-packaged release. This is particularly true if you choose the ``current'' sources. It is recommended that you read Staying current with FreeBSD.
You will need two things: The CTM program and the initial deltas to feed it (to get up to ``current'' levels).
The CTM program has been part of FreeBSD ever since version 2.0 was released, and lives in /usr/src/usr.sbin/CTM if you have a copy of the source online.
If you are running a pre-2.0 version of FreeBSD, you can fetch the current CTM sources directly from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm/
The ``deltas'' you feed CTM can be had two ways, FTP or e-mail. If you have general FTP access to the Internet then the following FTP sites support access to CTM:
ftp://ftp.FreeBSD.org/pub/FreeBSD/CTM/
or see section mirrors.
FTP the relevant directory and fetch the README file, starting from there.
If you may wish to get your deltas via email:
Send email to <majordomo@FreeBSD.org> to subscribe to one of the CTM distribution lists. ``ctm-cvs-cur'' supports the entire cvs tree. ``ctm-src-cur'' supports the head of the development branch. ``ctm-src-2_2'' supports the 2.2 release branch, etc. (If you do not know how to subscribe yourself using majordomo, send a message first containing the word help --- it will send you back usage instructions.)
When you begin receiving your CTM updates in the mail, you may use the ctm_rmail program to unpack and apply them. You can actually use the ctm_rmail program directly from a entry in /etc/aliases if you want to have the process run in a fully automated fashion. Check the ctm_rmail man page for more details.
Note: No matter what method you use to get the CTM deltas, you should subscribe to the <ctm-announce@FreeBSD.org> mailing list. In the future, this will be the only place where announcements concerning the operations of the CTM system will be posted. Send an email to <majordomo@FreeBSD.org> with a single line of subscribe ctm-announce to get added to the list.
Before you can start using CTM deltas, you will need to get to a starting point for the deltas produced subsequently to it.
First you should determine what you already have. Everyone can start from an ``empty'' directory. You must use an initial ``Empty'' delta to start off your CTM supported tree. At some point it is intended that one of these ``started'' deltas be distributed on the CD for your convenience. This does not currently happen however.
However, since the trees are many tens of megabytes, you should prefer to start from something already at hand. If you have a RELEASE CD, you can copy or extract an initial source from it. This will save a significant transfer of data.
You can recognize these ``starter'' deltas by the X appended to the number (src-cur.3210XEmpty.gz for instance). The designation following the X corresponds to the origin of your initial ``seed''. Empty is an empty directory. As a rule a base transition from Empty is produced every 100 deltas. By the way, they are large! 25 to 30 Megabytes of gzip'ed data is common for the XEmpty deltas.
Once you've picked a base delta to start from, you will also need all deltas with higher numbers following it.
To apply the deltas, simply say:
# cd /where/ever/you/want/the/stuff
# ctm -v -v /where/you/store/your/deltas/src-xxx.*
CTM understands deltas which have been put through gzip, so you do not need to gunzip them first, this saves disk space.
Unless it feels very secure about the entire process, CTM will not touch your tree. To verify a delta you can also use the -c flag and CTM will not actually touch your tree; it will merely verify the integrity of the delta and see if it would apply cleanly to your current tree.
There are other options to CTM as well, see the manual pages or look in the sources for more information.
I would also be very happy if somebody could help with the ``user interface'' portions, as I have realized that I cannot make up my mind on what options should do what, how and when...
That's really all there is to it. Every time you get a new delta, just run it through CTM to keep your sources up to date.
Do not remove the deltas if they are hard to download again. You just might want to keep them around in case something bad happens. Even if you only have floppy disks, consider using fdwrite to make a copy.
As a developer one would like to experiment with and change files in the source tree. CTM supports local modifications in a limited way: before checking for the presence of a file foo, it first looks for foo.ctm. If this file exists, CTM will operate on it instead of foo.
This behaviour gives us a simple way to maintain local changes: simply copy the files you plan to modify to the corresponding file names with a .ctm suffix. Then you can freely hack the code, while CTM keeps the .ctm file up-to-date.
You can determine the list of changes that CTM will make on your source repository using the -l option to CTM.
This is useful if you would like to keep logs of the changes, pre- or post- process the modified files in any manner, or just are feeling a tad paranoid :-).
Sometimes you may want to backup all the files that would be changed by a CTM update.
Specifying the -B backup-file option causes CTM to backup all files that would be touched by a given CTM delta to backup-file.
Sometimes you would be interested in restricting the scope of a given CTM update, or may be interested in extracting just a few files from a sequence of deltas.
You can control the list of files that CTM would operate on by specifying filtering regular expressions using the -e and -x options.
For example, to extract an up-to-date copy of lib/libc/Makefile from your collection of saved CTM deltas, run the commands:
# cd /where/ever/you/want/to/extract/it/
# ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.*
For every file specified in a CTM delta, the -e and -x options are applied in the order given on the command line. The file is processed by CTM only if it is marked as eligible after all the -e and -x options are applied to it.
Tons of them:
Use some kind of authentication into the CTM system, so as to allow detection of spoofed CTM updates.
Clean up the options to CTM, they became confusing and counter intuitive.
The bad news is that I am very busy, so any help in doing this will be most welcome. And do not forget to tell me what you want also...
All the ``DES infected'' (e.g. export controlled) source is not included. You will get the ``international'' version only. If sufficient interest appears, we will set up a sec-cur sequence too. There is a sequence of deltas for the ports collection too, but interest has not been all that high yet. Tell me if you want an email list for that too and we will consider setting it up.
for his pointed pen and invaluable comments.
for patience.
wrote ctm_[rs]mail, much appreciated.
for being so stubborn that I had to make it better.
I hope you like it...
Contributed by John Polstra <jdp@FreeBSD.org>.
CVSup is a software package for distributing and updating source trees from a master CVS repository on a remote server host. The FreeBSD sources are maintained in a CVS repository on a central development machine in California. With CVSup, FreeBSD users can easily keep their own source trees up to date.
CVSup uses the so-called pull model of updating. Under the pull model, each client asks the server for updates, if and when they are wanted. The server waits passively for update requests from its clients. Thus all updates are instigated by the client. The server never sends unsolicited updates. Users must either run the CVSup client manually to get an update, or they must set up a cron job to run it automatically on a regular basis.
The term CVSup, capitalized just so, refers to the entire software package. Its main components are the client cvsup which runs on each user's machine, and the server cvsupd which runs at each of the FreeBSD mirror sites.
As you read the FreeBSD documentation and mailing lists, you may see references to sup. Sup was the predecessor of CVSup, and it served a similar purpose. CVSup is in used in much the same way as sup and, in fact, uses configuration files which are backward-compatible with sup's. Sup is no longer used in the FreeBSD project, because CVSup is both faster and more flexible.
The easiest way to install CVSup if you are running FreeBSD 2.2 or later is to use either the port from the FreeBSD ports collection or the corresponding binary package, depending on whether you prefer to roll your own or not. If you do not know anything about cvsup at all and want a single package which will install it, set up the configuration file and start the transfer via a pointy-clicky type of interface, then get the cvsupit package. Just hand it to pkg_add(1) and it will lead you through the configuration process in a menu-oriented fashion.
If you are running FreeBSD-2.1.6 or 2.1.7, you unfortunately cannot use the binary package versions due to the fact that they require a version of the C library that does not yet exist in FreeBSD-2.1.{6,7}. You can easily use the port, however, just as with FreeBSD 2.2. Simply unpack the tar file, cd to the cvsup subdirectory and type make install.
Because CVSup is written in Modula-3, both the package and the port require that the Modula-3 runtime libraries be installed. These are available as the lang/modula-3-lib port and the lang/modula-3-lib-3.6 package. If you follow the same directions as for cvsup, these libraries will be compiled and/or installed automatically when you install the CVSup port or package.
The Modula-3 libraries are rather large, and fetching and compiling them is not an instantaneous process. For that reason, a third option is provided. You can get statically linked FreeBSD executables for CVSup from the USA distribution site:
ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsup-bin-16.0.tar.gz (client including GUI).
ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsup.nogui-bin-16.0.tar.gz (client without GUI).
ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupd-bin-16.0.tar.gz (server).
as well as from the many FreeBSD FTP mirror sites around the world.
Most users will need only the client. These executables are entirely self-contained, and they will run on any version of FreeBSD from FreeBSD-2.1.0 to FreeBSD-current.
In summary, your options for installing CVSup are:
FreeBSD-2.2 or later: static binary, port, or package
FreeBSD-2.1.6, 2.1.7: static binary or port
FreeBSD-2.1.5 or earlier: static binary
CVSup's operation is controlled by a configuration file called the supfile. Beginning with FreeBSD-2.2, there are some sample supfiles in the directory /usr/share/examples/cvsup/. These examples are also available from ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/ if you are on a pre-2.2 system.
The information in a supfile answers the following questions for cvsup:
In the following sections, we will construct a typical supfile by answering each of these questions in turn. First, we describe the overall structure of a supfile.
A supfile is a text file. Comments begin with # and extend to the end of the line. Lines that are blank and lines that contain only comments are ignored.
Each remaining line describes a set of files that the user wishes to receive. The line begins with the name of a ``collection'', a logical grouping of files defined by the server. The name of the collection tells the server which files you want. After the collection name come zero or more fields, separated by white space. These fields answer the questions listed above. There are two types of fields: flag fields and value fields. A flag field consists of a keyword standing alone, e.g., delete or compress. A value field also begins with a keyword, but the keyword is followed without intervening white space by = and a second word. For example, release=cvs is a value field.
A supfile typically specifies more than one collection to receive. One way to structure a supfile is to specify all of the relevant fields explicitly for each collection. However, that tends to make the supfile lines quite long, and it is inconvenient because most fields are the same for all of the collections in a supfile. CVSup provides a defaulting mechanism to avoid these problems. Lines beginning with the special pseudo-collection name *default can be used to set flags and values which will be used as defaults for the subsequent collections in the supfile. A default value can be overridden for an individual collection, by specifying a different value with the collection itself. Defaults can also be changed or augmented in mid-supfile by additional *default lines.
With this background, we will now proceed to construct a supfile for receiving and updating the main source tree of FreeBSD-current.
Which files do you want to receive?
The files available via CVSup are organized into named groups called ``collections''. The collections that are available are described here. In this example, we wish to receive the entire main source tree for the FreeBSD system. There is a single large collection src-all which will give us all of that, except the export-controlled cryptography support. Let us assume for this example that we are in the USA or Canada. Then we can get the cryptography code with one additional collection, cvs-crypto. As a first step toward constructing our supfile, we simply list these collections, one per line:
src-all
cvs-crypto
Which version(s) of them do you want?
With CVSup, you can receive virtually any version of the sources that ever existed. That is possible because the cvsupd server works directly from the CVS repository, which contains all of the versions. You specify which one of them you want using the tag= and date= value fields.
Warning: Be very careful to specify any tag= fields correctly. Some tags are valid only for certain collections of files. If you specify an incorrect or misspelled tag, CVSup will delete files which you probably do not want deleted. In particular, use only tag=. for the ports-* collections.
The tag= field names a symbolic tag in the repository. There are two kinds of tags, revision tags and branch tags. A revision tag refers to a specific revision. Its meaning stays the same from day to day. A branch tag, on the other hand, refers to the latest revision on a given line of development, at any given time. Because a branch tag does not refer to a specific revision, it may mean something different tomorrow than it means today.
Here are the branch tags that users might be interested in:
The main line of development, also known as FreeBSD-current.
Note: The . is not punctuation; it is the name of the tag. Valid for all collections.
The line of development for FreeBSD-3.x, also known as FreeBSD-stable. Not valid for the ports collection.
The line of development for FreeBSD-2.2.x, also known as 2.2-stable. Not valid for the ports collection.
The line of development for FreeBSD-2.1.x - this branch is largely obsolete. Not valid for the ports-* collections.
Here are the revision tags that users might be interested in:
FreeBSD-3.3. Not valid for the ports-* collections.
FreeBSD-3.2. Not valid for the ports-* collections.
FreeBSD-3.1. Not valid for the ports-* collections.
FreeBSD-3.0. Not valid for the ports-* collections.
FreeBSD-2.2.8. Not valid for the ports-* collections.
FreeBSD-2.2.7. Not valid for the ports-* collections.
FreeBSD-2.2.6. Not valid for the ports-* collections.
FreeBSD-2.2.5. Not valid for the ports-* collections.
FreeBSD-2.2.2. Not valid for the ports-* collections.
FreeBSD-2.2.1. Not valid for the ports-* collections.
FreeBSD-2.2.0. Not valid for the ports-* collections.
FreeBSD-2.1.7. Not valid for the ports-* collections.
FreeBSD-2.1.6.1. Not valid for the ports-* collections.
FreeBSD-2.1.6. Not valid for the ports-* collections.
FreeBSD-2.1.5. Not valid for the ports-* collections.
FreeBSD-2.1.0. Not valid for the ports-* collections.
Warning: Be very careful to type the tag name exactly as shown. CVSup cannot distinguish between valid and invalid tags. If you misspell the tag, CVSup will behave as though you had specified a valid tag which happens to refer to no files at all. It will delete your existing sources in that case.
When you specify a branch tag, you normally receive the latest versions of the files on that line of development. If you wish to receive some past version, you can do so by specifying a date with the date= value field. The cvsup(1) manual page explains how to do that.
For our example, we wish to receive FreeBSD-current. We add this line at the beginning of our supfile:
*default tag=.
There is an important special case that comes into play if you specify neither a tag= field nor a date= field. In that case, you receive the actual RCS files directly from the server's CVS repository, rather than receiving a particular version. Developers generally prefer this mode of operation. By maintaining a copy of the repository itself on their systems, they gain the ability to browse the revision histories and examine past versions of files. This gain is achieved at a large cost in terms of disk space, however.
Where do you want to get them from?
We use the host= field to tell cvsup where to obtain its updates. Any of the CVSup mirror sites will do, though you should try to select one that is close to you in cyberspace. In this example we will use a fictional FreeBSD distribution site, cvsup666.FreeBSD.org:
*default host=cvsup666.FreeBSD.org
You will need to change the host to one that actually exists before running CVSup. On any particular run of cvsup, you can override the host setting on the command line, with -h hostname.
Where do you want to put them on your own machine?
The prefix= field tells cvsup where to put the files it receives. In this example, we will put the source files directly into our main source tree, /usr/src. The src directory is already implicit in the collections we have chosen to receive, so this is the correct specification:
*default prefix=/usr
Where should cvsup maintain its status files?
The cvsup client maintains certain status files in what is called the ``base'' directory. These files help CVSup to work more efficiently, by keeping track of which updates you have already received. We will use the standard base directory, /usr/local/etc/cvsup:
*default base=/usr/local/etc/cvsup
This setting is used by default if it is not specified in the supfile, so we actually do not need the above line.
If your base directory does not already exist, now would be a good time to create it. The cvsup client will refuse to run if the base directory does not exist.
Miscellaneous supfile settings:
There is one more line of boiler plate that normally needs to be present in the supfile:
*default release=cvs delete use-rel-suffix compress
release=cvs indicates that the server should get its information out of the main FreeBSD CVS repository. This is virtually always the case, but there are other possibilities which are beyond the scope of this discussion.
delete gives CVSup permission to delete files. You should always specify this, so that CVSup can keep your source tree fully up to date. CVSup is careful to delete only those files for which it is responsible. Any extra files you happen to have will be left strictly alone.
use-rel-suffix is ... arcane. If you really want to know about it, see the cvsup(1) manual page. Otherwise, just specify it and do not worry about it.
compress enables the use of gzip-style compression on the communication channel. If your network link is T1 speed or faster, you probably should not use compression. Otherwise, it helps substantially.
Putting it all together:
Here is the entire supfile for our example:
*default tag=.
*default host=cvsup666.FreeBSD.org
*default prefix=/usr
*default base=/usr/local/etc/cvsup
*default release=cvs delete use-rel-suffix compress
src-all
cvs-crypto
You are now ready to try an update. The command line for doing this is quite simple:
# cvsup supfile
where supfile is of course the name of the supfile you have just created. Assuming you are running under X11, cvsup will display a GUI window with some buttons to do the usual things. Press the ``go'' button, and watch it run.
Since you are updating your actual /usr/src tree in this example, you will need to run the program as root so that cvsup has the permissions it needs to update your files. Having just created your configuration file, and having never used this program before, that might understandably make you nervous. There is an easy way to do a trial run without touching your precious files. Just create an empty directory somewhere convenient, and name it as an extra argument on the command line:
# mkdir /var/tmp/dest
# cvsup supfile /var/tmp/dest
The directory you specify will be used as the destination directory for all file updates. CVSup will examine your usual files in /usr/src, but it will not modify or delete any of them. Any file updates will instead land in /var/tmp/dest/usr/src. CVSup will also leave its base directory status files untouched when run this way. The new versions of those files will be written into the specified directory. As long as you have read access to /usr/src, you do not even need to be root to perform this kind of trial run.
If you are not running X11 or if you just do not like GUIs, you should add a couple of options to the command line when you run cvsup:
# cvsup -g -L 2 supfile
The -g tells cvsup not to use its GUI. This is automatic if you are not running X11, but otherwise you have to specify it.
The -L 2 tells cvsup to print out the details of all the file updates it is doing. There are three levels of verbosity, from -L 0 to -L 2. The default is 0, which means total silence except for error messages.
There are plenty of other options available. For a brief list of them, type cvsup -H. For more detailed descriptions, see the manual page.
Once you are satisfied with the way updates are working, you can arrange for regular runs of cvsup using cron(8). Obviously, you should not let cvsup use its GUI when running it from cron.
The file collections available via CVSup are organized hierarchically. There are a few large collections, and they are divided into smaller sub-collections. Receiving a large collection is equivalent to receiving each of its sub-collections. The hierarchical relationships among collections are reflected by the use of indentation in the list below.
The most commonly used collections are src-all, cvs-crypto, and ports-all. The other collections are used only by small groups of people for specialized purposes, and some mirror sites may not carry all of them.
The main FreeBSD CVS repository, excluding the export-restricted cryptography code.
Files related to the distribution and mirroring of FreeBSD.
Sources for the FreeBSD handbook and other documentation.
The FreeBSD ports collection.
Archiving tools.
Astronomical ports.
Sound support.
Miscellaneous files at the top of /usr/ports.
Benchmarks.
Biology.
Computer aided design tools.
Chinese language support.
Communication software.
character code converters.
Databases.
Things that used to be on the desktop before computers were invented.
Development utilities.
Editors.
Emulators for other operating systems.
FTP client and server utilities.
Games.
German language support.
Graphics utilities.
Japanese language support.
Korean language support.
Programming languages.
Mail software.
Numerical computation software.
MBone applications.
Miscellaneous utilities.
Networking software.
USENET news software.
Software support for 3Com Palm(tm) series.
Various programs from Plan9.
Printing software.
Russian language support.
Security utilities.
Command line shells.
System utilities.
text processing utilities (does not include desktop publishing).
Vietnamese language support.
Software related to the World Wide Web.
Ports to support the X window system.
X11 clocks.
X11 file managers.
X11 fonts and font utilities.
X11 toolkits.
X11 window managers.
The main FreeBSD sources, excluding the export-restricted cryptography code.
Miscellaneous files at the top of /usr/src.
User utilities that may be needed in single-user mode (/usr/src/bin).
Utilities and libraries from outside the FreeBSD project, used relatively unmodified (/usr/src/contrib).
System configuration files (/usr/src/etc).
Games (/usr/src/games).
Utilities covered by the GNU Public License (/usr/src/gnu).
Header files (/usr/src/include).
KerberosIV security package (/usr/src/kerberosIV).
Libraries (/usr/src/lib).
System programs normally executed by other programs (/usr/src/libexec).
Files required to produce a FreeBSD release (/usr/src/release).
System utilities for single-user mode (/usr/src/sbin).
Files that can be shared across multiple systems (/usr/src/share).
The kernel (/usr/src/sys).
Various tools for the maintenance of FreeBSD (/usr/src/tools).
User utilities (/usr/src/usr.bin).
System utilities (/usr/src/usr.sbin).
The sources for the World Wide Web data.
The export-restricted cryptography code.
Export-restricted utilities and libraries from outside the FreeBSD project, used relatively unmodified (/usr/src/crypto).
Kerberos and DES (/usr/src/eBones).
DES (/usr/src/secure).
The CVSup server's own configuration files. Used by CVSup mirror sites.
The GNATS bug-tracking database.
FreeBSD mailing list archive.
The installed World Wide Web data. Used by WWW mirror sites.
For the CVSup FAQ and other information about CVSup, see The CVSup Home Page.
Most FreeBSD-related discussion of CVSup takes place on the FreeBSD technical discussions mailing list <freebsd-hackers@FreeBSD.org>. New versions of the software are announced there, as well as on the FreeBSD announcements mailing list <freebsd-announce@FreeBSD.org>.
Questions and bug reports should be addressed to the author of the program at <cvsup-bugs@polstra.com>.