Obtaining &os;CDROM and DVD PublishersCD and DVD Sets&os; CD and DVD sets are available from many online
retailers:&os; Mall, Inc.2420 Sand Creek Rd C-1 #347Brentwood,
CA94513USA
Phone: +1 925 240-6652
Fax: +1 925 674-0821
Email: info@freebsdmall.com
WWW: Dr. Hinner EDVKochelseestr. 11D-81371MünchenGermany
Phone: (0177) 428 419 0
WWW: Linux Distro UK42 Wharfedale RoadMargateCT9 2TBUnited Kingdom
WWW: The Linux EmporiumThe Techno Centre, Puma WayParksideCV1 2TTUnited Kingdom
Phone: +44 (0)247 615 8121
Fax: +44 1491 837016
WWW: LinuxCenter.RuGalernaya Street, 55Saint-Petersburg190000Russia
Phone: +7-812-3125208
Email: info@linuxcenter.ru
WWW: FTP SitesThe official sources for &os; are available via anonymous
FTP from a worldwide set of mirror sites. The site
is well
connected and allows a large number of connections to it, but
you are probably better off finding a closer
mirror site (especially if you decide to set up some sort of
mirror site).Additionally, &os; is available via anonymous FTP from the
following mirror sites. If you choose to obtain &os; via
anonymous FTP, please try to use a site near you. The mirror
sites listed as Primary Mirror Sites typically
have the entire &os; archive (all the currently available
versions for each of the architectures) but you will probably
have faster download times from a site that is in your country
or region. The regional sites carry the most recent versions
for the most popular architecture(s) but might not carry the
entire &os; archive. All sites provide access via anonymous FTP
but some sites also provide access via other methods. The
access methods available for each site are provided in
parentheses after the hostname.
&chap.mirrors.ftp.index.inc;
&chap.mirrors.lastmod.inc;
&chap.mirrors.ftp.inc;
Anonymous CVS (Deprecated)WarningCVS has been deprecated by the project, and its use is
not recommended.
Subversion
should be used instead.Using CTMCTMCTM is a method for keeping a
remote directory tree in sync with a central one. It has been
developed for usage with &os;'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 contact the
&a.ctm-users.name; mailing list for more information and if you
wish to use CTM for other
things.Why Should I Use CTM?CTM will give you a local copy
of the &os; 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 &os;, 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
large 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 &os;.What Do I Need to Use
CTM?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 &os; ever since version 2.0 was released, and lives in
/usr/src/usr.sbin/ctm if you have a copy
of the source available.The deltas you feed
CTM can be had two ways, FTP or
email. If you have general FTP access to the Internet then
the following FTP sites support access to
CTM:or see section mirrors.FTP the relevant directory and fetch the
README file, starting from there.If you wish to get your deltas via email:Subscribe to one of the
CTM distribution lists.
&a.ctm-src-cur.name; supports the entire Subversion tree.
&a.ctm-src-cur.name; supports the head of the development
branch. &a.ctm-src-9.name; supports the 9.X release branch,
etc.. (If you do not know how to subscribe yourself to a
list, click on the list name above or go to
&a.mailman.lists.link; and click on the list that you wish to
subscribe to. The list page should contain all of the
necessary subscription 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 manual page for more
details.No matter what method you use to get the
CTM deltas, you should subscribe
to the &a.ctm-announce.name; mailing list. In the future,
this will be the only place where announcements concerning
the operations of the CTM system
will be posted. Click on the list name above and follow the
instructions to subscribe to the list.Using CTM for the First
TimeBefore 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, however, this does not currently
happen.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! 70 to 80
Megabytes of gzip'd data is common for the
XEmpty deltas.Once you have picked a base delta to start from, you will
also need all deltas with higher numbers following it.Using CTM in Your Daily
LifeTo apply the deltas, simply say:&prompt.root; cd /where/ever/you/want/the/stuff
&prompt.root; 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 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.That is 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.Keeping Your Local ChangesAs 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 behavior 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.Other Interesting CTM
OptionsFinding Out Exactly What Would Be Touched by an
UpdateYou can determine the list of changes that
CTM will make on your source
repository using the 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.Making Backups Before UpdatingSometimes you may want to backup all the files that
would be changed by a CTM
update.Specifying the option
causes CTM to backup all files
that would be touched by a given
CTM delta to
backup-file.Restricting the Files Touched by an UpdateSometimes 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
and options.For example, to extract an up-to-date copy of
lib/libc/Makefile from your collection
of saved CTM deltas, run the
commands:&prompt.root; cd /where/ever/you/want/to/extract/it/
&prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.*For every file specified in a
CTM delta, the
and 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 and
options are applied to it.Future Plans for CTMTons 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.Miscellaneous StuffThere is a sequence of deltas for the
ports collection too, but interest has not
been all that high yet.CTM MirrorsCTM/&os; is available via
anonymous FTP from the following mirror sites. If you choose
to obtain CTM via anonymous FTP,
please try to use a site near you.In case of problems, please contact the &a.ctm-users.name;
mailing list.California, Bay Area, official sourceSouth Africa, backup server for old deltasTaiwan/R.O.C.If you did not find a mirror near to you or the mirror is
incomplete, try to use a search engine such as alltheweb.Using SubversionSubversionIntroductionAs of July 2012, &os; uses Subversion
(svn) as the primary version control
system for storing all of &os;'s source code, documentation,
and the Ports Collection.Subversion is generally a developer tool. Most users
should use FreeBSD
Update to update the &os; base system, and Portsnap to
update the &os; Ports Collection.In Subversion, URLs are used to
designate a repository, taking the form of
protocol://hostname/path. Mirrors
may support different protocols as specified below. The first
component of the path is the &os; repository to access. There
are three different repositories, base for
the &os; base system source code, ports for
the Ports Collection, and doc for
documentation. For example, the URL
svn://svn0.us-east.FreeBSD.org/ports/head/
specifies the main branch of the ports repository on the
svn0.us-east.FreeBSD.org mirror,
using the svn protocol.InstallationSubversion must be installed
before it can be used to check out the contents of any of the
repositories. If a copy of the ports tree is already present,
one can install Subversion like
this:&prompt.root; cd /usr/ports/devel/subversion
&prompt.root; make install cleanIf the ports tree is not available,
Subversion can be installed as a
package:&prompt.root; pkg_add -r subversionIf pkgng is being used to
manage packages, Subversion can be
installed with it instead:&prompt.root; pkg install devel/subversionRunning SubversionThe svn command is used to fetch a
clean copy of the sources into a local directory. The files
in this directory are called a local working
copy.If the local directory already exists but was not
created by svn, rename or delete it
before the checkout. Checkout over an existing
non-svn directory can cause conflicts
between the existing files and those brought in from the
repository.A checkout from a given repository is performed with a
command like this:&prompt.root; svn checkout svn-mirror/repository/branchlwcdirwhere:svn-mirror is a URL for one
of the Subversion mirror
sites.repository is one of the
Project repositories, i.e., base,
ports, or
doc.branch depends on the
repository used. ports and
doc are mostly updated in the
head branch, while
base maintains the latest version of
-CURRENT under head and the respective
latest versions of the -STABLE branches under
stable/8 (for
8.x) and
stable/9
(9.x).lwcdir is the target
directory where the contents of the specified branch
should be placed. This is usually
/usr/ports for
ports,
/usr/src for
base, and
/usr/doc for
doc.This example checks out the Ports Collection from the
western US repository using the HTTPS
protocol, placing the local working copy in
/usr/ports. If
/usr/ports is already
present but was not created by svn,
remember to rename or delete it before the checkout.&prompt.root; svn checkout https://svn0.us-west.FreeBSD.org/ports/head /usr/portsBecause the initial checkout has to download the full
branch of the remote repository, it can take a while. Please
be patient.After the initial checkout, the local working copy can be
updated by running:&prompt.root; svn update lwcdirTo update
/usr/ports created in
the example above, use:&prompt.root; svn update /usr/portsThe update is much quicker than a checkout, only
transferring files that have changed.An alternate way of updating the local working copy after
checkout is provided by the Makefile in
the /usr/ports,
/usr/src, and
/usr/doc directories.
Set SVN_UPDATE and use the
update target. For example, to
update /usr/src:&prompt.root; cd /usr/src
&prompt.root; make update SVN_UPDATE=yesFor More InformationFor other information about using
Subversion, please see the
Subversion Book, titled
Version Control with
Subversion, or the
Subversion
Documentation.Subversion Mirror SitesSubversion RepositoryMirror SitesAll mirrors carry all repositories.The master &os; Subversion
server, svn.FreeBSD.org, is
publicly accessible, read-only. That may change in the future,
so users are encouraged to use one of the official mirrors. To
view the &os; Subversion repositories
through a browser, use http://svnweb.FreeBSD.org/.The &os; svn mirror network is still in its early days,
and will likely change. Do not count on this list of mirrors
being static. In particular, the SSL certificates of the
servers will likely change at some point.NameProtocolsLocationSSL fingerprintsvn0.us-west.FreeBSD.orgsvn, http,
httpsUSA, CaliforniaSHA1
1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61svn0.us-east.FreeBSD.orgsvn, http,
https, rsyncUSA, New JerseySHA1
1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61svn0.eu.FreeBSD.orgsvn, http,
https, rsyncEurope, UKSHA1
39:B0:53:35:CE:60:C7:BB:00:54:96:96:71:10:94:BB:CE:1C:07:A7HTTPS is the preferred protocol,
providing protection against another computer pretending to be
the &os; mirror (commonly known as a man in the
middle attack) or otherwise trying to send bad content
to the end user.On the first connection to an HTTPS
mirror, the user will be asked to verify the server
fingerprint:Error validating server certificate for 'https://svn0.us-west.freebsd.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
- The certificate hostname does not match.
Certificate information:
- Hostname: svnmir.ysv.FreeBSD.org
- Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT
- Issuer: clusteradm, FreeBSD.org, (null), CA, US (clusteradm@FreeBSD.org)
- Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
(R)eject, accept (t)emporarily or accept (p)ermanently?Compare the fingerprint shown to those listed in the table
above. If the fingerprint matches, the server security
certificate can be accepted temporarily or permanently. A
temporary certificate will expire after a single session with
the server, and the verification step will be repeated on the
next connection. Accepting the certificate permanently will
store the authentication credentials in
~/.subversion/auth/ and
the user will not be asked to verify the fingerprint again until
the certificate expires.If HTTPS cannot be used due to firewall
or other problems, SVN is the next choice,
with slightly faster transfers. When neither can be used, use
HTTP.Using CVSup (Deprecated)Introductioncvsup has been deprecated by the
project, and its use is not recommended.
Subversion should be used
instead.CVSup is a software package for
distributing and updating source trees from a master CVS
repository on a remote server host. The &os; sources are
maintained in a CVS repository on a central development
machine in California. With CVSup,
&os; 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 &os;
mirror sites.The csup utility is a rewrite
of the CVSup software in C. Its
biggest advantage is, that it is faster and does not depend
on the Modula-3 language, thus you do not need to install it
as a requirement. Moreover you can use it out-of-the-box,
since it is included in the base system. If you decided to
use csup, just skip the steps on
the installation of CVSup and
substitute the references of
CVSup with
csup while following the
remainder of this article.InstallationThe easiest way to install
CVSup is to use the precompiled
net/cvsup package from the
&os; packages collection. If you
prefer to build CVSup from source,
you can use the net/cvsup
port instead. But be forewarned: the net/cvsup port depends on the
Modula-3 system, which takes a substantial amount of time and
disk space to download and build.If you are going to be using
CVSup on a machine which will not
have &xorg; installed, such as a
server, be sure to use the port which does not include the
CVSup GUI,
net/cvsup-without-gui.CVSup ConfigurationCVSup's operation is controlled
by a configuration file called the
supfile. There are some sample
supfiles in the directory /usr/share/examples/cvsup/.The information in a supfile answers
the following questions for
CVSup:Which files do you
want to receive?Which versions of
them do you want?Where do you want
to get them from?Where do you want to
put them on your own machine?Where do you want
to put your status files?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
&os;-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 in the
following section. In
this example, we wish to receive the entire main source
tree for the &os; system. There is a single large
collection src-all which will give us
all of that. As a first step toward constructing our
supfile, we simply list the
collections, one per line (in this case, only one
line):src-allWhich 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
value fields.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. contains branch tags that
users might be interested in. When specifying a tag in
CVSup's configuration file, it
must be preceded with tag=
(RELENG_8 will become
tag=RELENG_8).
Keep in mind that only the tag=. is
relevant for the Ports Collection.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
value field. The &man.cvsup.1;
manual page explains how to do that.For our example, we wish to receive &os;-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 &os; distribution site,
cvsup99.FreeBSD.org:*default host=cvsup99.FreeBSD.orgYou 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
.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=/usrWhere 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,
/var/db:*default base=/var/dbIf 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 compressrelease=cvs indicates that the
server should get its information out of the main &os; 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 &man.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=cvsup99.FreeBSD.org
*default prefix=/usr
*default base=/var/db
*default release=cvs delete use-rel-suffix compress
src-allThe refuse FileAs mentioned above, CVSup
uses a pull method. Basically, this
means that you connect to the
CVSup server, and it says,
Here is what you can download from me..., and
your client responds
OK, I will take this, this, this, and this.
In the default configuration, the
CVSup client will take every file
associated with the collection and tag you chose in the
configuration file. In order to download a partial tree,
use the refuse file.The refuse file tells
CVSup that it should not take
every single file from a collection; in other words, it
tells the client to refuse certain
files from the server. The refuse file
can be found (or, if you do not yet have one, should be
placed) in
base/sup/.
base is defined in your
supfile; our defined
base is
/var/db, which means that by default
the refuse file is
/var/db/sup/refuse.The refuse file has a very simple
format; it simply contains the names of files or directories
that you do not wish to download. For example:bin/
usr.bin/Users who are on
slow links or pay by the minute for their Internet
connection will be able to save time as they will
no longer need to download files that they will never use.
For more information on refuse files
and other neat features of CVSup,
please view its manual page.Running CVSupYou are now ready to try an update. The command line for
doing this is quite simple:&prompt.root; cvsup supfilewhere
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:&prompt.root; mkdir /var/tmp/dest
&prompt.root; cvsup supfile /var/tmp/destThe 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:&prompt.root; cvsup -g -L 2 supfileThe tells
CVSup not to use its GUI. This is
automatic if you are not running X11, but otherwise you have
to specify it.The tells
CVSup to print out the
details of all the file updates it is doing. There are three
levels of verbosity, from to
. 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 &man.cron.8;.
Obviously, you should not let CVSup
use its GUI when running it from &man.cron.8;.CVSup File CollectionsThe 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 collection is
src-all. cvs-all release=cvsThe main &os; CVS repository, including the
cryptography code.distrib release=cvsFiles related to the distribution and
mirroring of &os;.projects-all release=cvsSources for the &os; projects
repository.src-all release=cvsThe main &os; sources, including the
cryptography code.src-base
release=cvsMiscellaneous files at the top of
/usr/src.src-bin
release=cvsUser utilities that may be needed in
single-user mode
(/usr/src/bin).src-cddl
release=cvsUtilities and libraries covered by the
CDDL license
(/usr/src/cddl).src-contrib
release=cvsUtilities and libraries from outside the
&os; project, used relatively unmodified
(/usr/src/contrib).src-crypto release=cvsCryptography utilities and libraries
from outside the &os; project, used
relatively unmodified
(/usr/src/crypto).src-eBones release=cvsKerberos and DES
(/usr/src/eBones). Not
used in current releases of &os;.src-etc
release=cvsSystem configuration files
(/usr/src/etc).src-games
release=cvsGames
(/usr/src/games).src-gnu
release=cvsUtilities covered by the GNU Public
License
(/usr/src/gnu).src-include
release=cvsHeader files
(/usr/src/include).src-kerberos5
release=cvsKerberos5 security package
(/usr/src/kerberos5).src-kerberosIV
release=cvsKerberosIV security package
(/usr/src/kerberosIV).src-lib
release=cvsLibraries
(/usr/src/lib).src-libexec
release=cvsSystem programs normally executed by
other programs
(/usr/src/libexec).src-release
release=cvsFiles required to produce a &os;
release
(/usr/src/release).src-rescue
release=cvsStatically linked programs for emergency
recovery; see &man.rescue.8;
(/usr/src/rescue).src-sbin release=cvsSystem utilities for single-user mode
(/usr/src/sbin).src-secure
release=cvsCryptographic libraries and commands
(/usr/src/secure).src-share
release=cvsFiles that can be shared across multiple
systems
(/usr/src/share).src-sys
release=cvsThe kernel
(/usr/src/sys).src-sys-crypto
release=cvsKernel cryptography code
(/usr/src/sys/crypto).src-tools
release=cvsVarious tools for the maintenance of
&os;
(/usr/src/tools).src-usrbin
release=cvsUser utilities
(/usr/src/usr.bin).src-usrsbin
release=cvsSystem utilities
(/usr/src/usr.sbin).distrib release=selfThe CVSup server's own
configuration files. Used by
CVSup mirror sites.gnats release=currentThe GNATS bug-tracking database.mail-archive release=current&os; mailing list archive.For More InformationFor the CVSup FAQ and other
information about CVSup, see
The
CVSup Home Page.Most &os;-related discussion of
CVSup takes place on the
&a.hackers;. New versions of the software are announced
there, as well as on the &a.announce;.For questions or bug reports about
CVSup take a look at the
CVSup FAQ.CVSup SitesCVSup servers for &os; are
running at the following sites:
&chap.mirrors.cvsup.index.inc;
&chap.mirrors.lastmod.inc;
&chap.mirrors.cvsup.inc;
CVS TagsCVS has been deprecated by the project, and its use is not
recommended. Subversion should be
used instead.When obtaining or updating sources using
cvs or
CVSup, a revision tag must be
specified. A revision tag refers to either a particular line of
&os; development, or a specific point in time. The first type
are called branch tags, and the second type are
called release tags.Branch TagsAll of these, with the exception of
HEAD (which is always a valid tag), only
apply to the src/ tree. The
ports/, doc/, and
www/ trees are not branched.HEADSymbolic name for the main line, or &os;-CURRENT.
Also the default when no revision is specified.In CVSup, this tag is
represented by a . (not punctuation,
but a literal . character).In CVS, this is the default when no revision tag
is specified. It is usually not
a good idea to checkout or update to CURRENT sources
on a STABLE machine, unless that is your
intent.RELENG_9The line of development for &os;-9.X, also known
as &os; 9-STABLERELENG_9_1The release branch for &os;-9.1, used only for
security advisories and other critical fixes.RELENG_9_0The release branch for &os;-9.0, used only for
security advisories and other critical fixes.RELENG_8The line of development for &os;-8.X, also known
as &os; 8-STABLERELENG_8_3The release branch for &os;-8.3, used only for
security advisories and other critical fixes.RELENG_8_2The release branch for &os;-8.2, used only for
security advisories and other critical fixes.RELENG_8_1The release branch for &os;-8.1, used only for
security advisories and other critical fixes.RELENG_8_0The release branch for &os;-8.0, used only for
security advisories and other critical fixes.RELENG_7The line of development for &os;-7.X, also known
as &os; 7-STABLERELENG_7_4The release branch for &os;-7.4, used only for
security advisories and other critical fixes.RELENG_7_3The release branch for &os;-7.3, used only for
security advisories and other critical fixes.RELENG_7_2The release branch for &os;-7.2, used only for
security advisories and other critical fixes.RELENG_7_1The release branch for &os;-7.1, used only for
security advisories and other critical fixes.RELENG_7_0The release branch for &os;-7.0, used only for
security advisories and other critical fixes.RELENG_6The line of development for &os;-6.X, also known
as &os; 6-STABLERELENG_6_4The release branch for &os;-6.4, used only for
security advisories and other critical fixes.RELENG_6_3The release branch for &os;-6.3, used only for
security advisories and other critical fixes.RELENG_6_2The release branch for &os;-6.2, used only for
security advisories and other critical fixes.RELENG_6_1The release branch for &os;-6.1, used only for
security advisories and other critical fixes.RELENG_6_0The release branch for &os;-6.0, used only for
security advisories and other critical fixes.RELENG_5The line of development for &os;-5.X, also known
as &os; 5-STABLE.RELENG_5_5The release branch for &os;-5.5, used only
for security advisories and other critical fixes.RELENG_5_4The release branch for &os;-5.4, used only
for security advisories and other critical fixes.RELENG_5_3The release branch for &os;-5.3, used only
for security advisories and other critical fixes.RELENG_5_2The release branch for &os;-5.2 and
&os;-5.2.1, used only for security advisories and other
critical fixes.RELENG_5_1The release branch for &os;-5.1, used only
for security advisories and other critical fixes.RELENG_5_0The release branch for &os;-5.0, used only
for security advisories and other critical fixes.RELENG_4The line of development for &os;-4.X, also known
as &os; 4-STABLE.RELENG_4_11The release branch for &os;-4.11, used only
for security advisories and other critical fixes.RELENG_4_10The release branch for &os;-4.10, used only
for security advisories and other critical fixes.RELENG_4_9The release branch for &os;-4.9, used only
for security advisories and other critical fixes.RELENG_4_8The release branch for &os;-4.8, used only
for security advisories and other critical fixes.RELENG_4_7The release branch for &os;-4.7, used only
for security advisories and other critical fixes.RELENG_4_6The release branch for &os;-4.6 and &os;-4.6.2,
used only for security advisories and other
critical fixes.RELENG_4_5The release branch for &os;-4.5, used only
for security advisories and other critical fixes.RELENG_4_4The release branch for &os;-4.4, used only
for security advisories and other critical fixes.RELENG_4_3The release branch for &os;-4.3, used only
for security advisories and other critical fixes.RELENG_3The line of development for &os;-3.X, also known
as 3.X-STABLE.RELENG_2_2The line of development for &os;-2.2.X, also known
as 2.2-STABLE. This branch is mostly obsolete.Release TagsThese tags refer to a specific point in time when a
particular version of &os; was released. The release
engineering process is documented in more detail by the
Release Engineering
Information and
Release
Process documents. The
src tree uses tag names
that start with RELENG_ tags. The
ports and
doc trees use tags
whose names begin with RELEASE tags.
Finally, the www tree
is not tagged with any special name for releases.RELENG_9_1_0_RELEASE&os; 9.1RELENG_9_0_0_RELEASE&os; 9.0RELENG_8_3_0_RELEASE&os; 8.3RELENG_8_2_0_RELEASE&os; 8.2RELENG_8_1_0_RELEASE&os; 8.1RELENG_8_0_0_RELEASE&os; 8.0RELENG_7_4_0_RELEASE&os; 7.4RELENG_7_3_0_RELEASE&os; 7.3RELENG_7_2_0_RELEASE&os; 7.2RELENG_7_1_0_RELEASE&os; 7.1RELENG_7_0_0_RELEASE&os; 7.0RELENG_6_4_0_RELEASE&os; 6.4RELENG_6_3_0_RELEASE&os; 6.3RELENG_6_2_0_RELEASE&os; 6.2RELENG_6_1_0_RELEASE&os; 6.1RELENG_6_0_0_RELEASE&os; 6.0RELENG_5_5_0_RELEASE&os; 5.5RELENG_5_4_0_RELEASE&os; 5.4RELENG_4_11_0_RELEASE&os; 4.11RELENG_5_3_0_RELEASE&os; 5.3RELENG_4_10_0_RELEASE&os; 4.10RELENG_5_2_1_RELEASE&os; 5.2.1RELENG_5_2_0_RELEASE&os; 5.2RELENG_4_9_0_RELEASE&os; 4.9RELENG_5_1_0_RELEASE&os; 5.1RELENG_4_8_0_RELEASE&os; 4.8RELENG_5_0_0_RELEASE&os; 5.0RELENG_4_7_0_RELEASE&os; 4.7RELENG_4_6_2_RELEASE&os; 4.6.2RELENG_4_6_1_RELEASE&os; 4.6.1RELENG_4_6_0_RELEASE&os; 4.6RELENG_4_5_0_RELEASE&os; 4.5RELENG_4_4_0_RELEASE&os; 4.4RELENG_4_3_0_RELEASE&os; 4.3RELENG_4_2_0_RELEASE&os; 4.2RELENG_4_1_1_RELEASE&os; 4.1.1RELENG_4_1_0_RELEASE&os; 4.1RELENG_4_0_0_RELEASE&os; 4.0RELENG_3_5_0_RELEASE&os;-3.5RELENG_3_4_0_RELEASE&os;-3.4RELENG_3_3_0_RELEASE&os;-3.3RELENG_3_2_0_RELEASE&os;-3.2RELENG_3_1_0_RELEASE&os;-3.1RELENG_3_0_0_RELEASE&os;-3.0RELENG_2_2_8_RELEASE&os;-2.2.8RELENG_2_2_7_RELEASE&os;-2.2.7RELENG_2_2_6_RELEASE&os;-2.2.6RELENG_2_2_5_RELEASE&os;-2.2.5RELENG_2_2_2_RELEASE&os;-2.2.2RELENG_2_2_1_RELEASE&os;-2.2.1RELENG_2_2_0_RELEASE&os;-2.2.0rsync SitesThe following sites make &os; available through the rsync
protocol. The rsync utility works in
much the same way as the &man.rcp.1; command,
but has more options and uses the rsync remote-update protocol
which transfers only the differences between two sets of files,
thus greatly speeding up the synchronization over the network.
This is most useful if you are a mirror site for the
&os; FTP server, or the CVS repository. The
rsync suite is available for many
operating systems, on &os;, see the
net/rsync
port or use the package.Czech Republicrsync://ftp.cz.FreeBSD.org/Available collections:ftp: A partial mirror of the &os; FTP
server.&os;: A full mirror of the &os; FTP server.Netherlandsrsync://ftp.nl.FreeBSD.org/Available collections:&os;: A full mirror of the &os; FTP server.Russiarsync://ftp.mtu.ru/Available collections:&os;: A full mirror of the &os; FTP server.&os;-gnats: The GNATS bug-tracking
database.&os;-Archive: The mirror of &os; Archive
FTP server.Swedenrsync://ftp4.se.freebsd.org/Available collections:&os;: A full mirror of the &os; FTP server.Taiwanrsync://ftp.tw.FreeBSD.org/rsync://ftp2.tw.FreeBSD.org/rsync://ftp6.tw.FreeBSD.org/Available collections:&os;: A full mirror of the &os; FTP server.United Kingdomrsync://rsync.mirrorservice.org/Available collections:ftp.freebsd.org: A full mirror of the &os;
FTP server.United States of Americarsync://ftp-master.FreeBSD.org/This server may only be used by &os; primary mirror
sites.Available collections:&os;: The master archive of the &os; FTP
server.acl: The &os; master ACL list.rsync://ftp13.FreeBSD.org/Available collections:&os;: A full mirror of the &os; FTP server.