--- current.mm	2002/01/01 02:22:25	4.1
+++ current.mm	2003/04/09 19:28:00
@@ -1,54 +1,139 @@
 .\" This file is in -*- nroff-fill -*- mode
-.\" STATUS: Review draft 4th edition
-.\" $Id: current.mm,v 4.1 2002/01/01 02:22:25 grog Exp $
+.\" STATUS: 4th edition
+.\" $Id: current.mm,v 4.17 2003/04/09 19:28:00 grog Exp $
 .\"
-.Chapter \*[nchcurrent] "Keeping up to date with FreeBSD"
-CD-ROMs are probably the cheapest way to get FreeBSD, but they're not the most
-up-to-date.  In this chapter, we'll look at how to keep your system up to date
-via the Internet.
+.Chapter \*[nchcurrent] "Keeping up to date"
+FreeBSD is constantly changing.  The average time that elapses between changes
+to the source tree is in the order of a few minutes.  Obviously you can't keep
+up to date with that pace of change.
 .P
+In the following three chapters we'll look at how to keep up to date.  In this
+chapter, we'll look at:
+.Ls B
+.LI
+FreeBSD releases: how the FreeBSD project comes to terms with the rapid rate of
+change, and how it keeps the system stable despite the changes.
+.LI
+How the system sources are stored, and how you can update them.
+.Le
+In
+.Sref "\*[chupgrading]" ,
+we'll look at how to upgrade FreeBSD to a new release, with particular reference
+to upgrades to FreeBSD Release 5, and in
+.Sref "\*[chbuild]" ,
+we'll look at building special kernels.
+.SPUP
+.H2 "FreeBSD releases and CVS"
 .Pn repository
-.X "repository, cvs"
-.X "cvs, repository"
+.X "repository, CVS"
+.X "CVS, repository"
 .X "Concurrent Versions System"
-.X "cvs"
+.X "CVS"
 .X "branch, CVS"
 .X "CVS, branch"
+.X "branch, CVS"
+.X "FreeBSD, releases"
+.X "Revision Control System"
+.X "RCS"
+.X "trunk, CVS"
+.X "CVS, trunk"
 The FreeBSD project keeps the entire operating system sources in a single master
 source tree, called a \fIrepository\fP, which is maintained by the \fIConcurrent
-Versions System\fP, or \fIcvs\fP.  It's included in most multi-CD-ROM
+Versions System\fP, or \fICVS\fP.  It's included in most multi\(enCD-ROM
 distributions of FreeBSD.  The repository contains all versions of FreeBSD back
-to the last release from the Computer Sciences Research Group of the University
-of California at Berkeley, 4.4BSD-Lite.  Each of these versions is called a
-\fIbranch\fP.  At any one time, There are three main versions of FreeBSD which
-are of interest.  We'll look at them in the following sections.
+to Release 2.0 and the last release from the Computer Sciences Research Group of
+the University of California at Berkeley, 4.4BSD-Lite, upon which it was based.
+For copyright reasons FreeBSD Release 1 was not included, because at the time,
+as the result of the lawsuits described on page
+.Sref \*[unixwars] ,
+it was not permitted to distribute it freely.  That situation changed in early
+2002, but it's now too late to include FreeBSD Release 1 in the repository.
+.P
+\fICVS\fP\/ is built on top of the \fIRevision Control System\fP, or \fIRCS\fP.
+\fIRCS\fP\/ keeps multiple versions of files, called \fIrevisions\fP, in a
+single RCS file.  Each revision has a number indicating its relationship to the
+other revisions.  The oldest revision has the number 1.1, the next oldest has
+the number 1.2, and so on.  The RCS file contains the most recent revision of
+the file along with instructions for creating any other revision.
+.P
+In addition to this linear sequence, it's possible to update a specific revision
+in more than one way.  The obvious way to update revision 1.2 would create
+revision 1.3; but it's also possible to create \fIbranches\fP, which get numbers
+like 1.2.1.1.  Updating revision 1.2.1.1 would create revision 1.2.1.2, and so
+on.  By contrast, the revisions with a two-part number are collectively called
+the \fItrunk\fP\/ of the tree.
+.H3 "Symbolic names or tags"
+.X "symbolic names, CVS"
+.X "tag, CVS"
+.X "CVS, symbolic names"
+.X "CVS, tag"
+In addition to the numeric identifiers, each of which relates only to a single
+file, RCS allows you to attach \fIsymbolic names\fP\/ to specific revisions.
+CVS generally calls these names \fItags\fP, and that's the term you'll see most
+often.  FreeBSD uses tags to indicate the revisions corresponding to a
+particular release.  For example, in the directory
+.Directory /usr/src/sys/kern ,
+revision 1.13 of
+.File kern_clock.c ,
+revision 1.12 of \fIkern_fork.c\fP\/ and revision 1.21.4.1 of \fIkern_exec.c\fP\/
+participate in \f(CWRELENG_2_1_0_RELEASE\fP.  We'll look at tags in more detail
+on page
+.Sref \*[release-tags] .
+.P
+\fIRCS\fP\/ stores its files either in the same directory as the working files
+it is tracking, or in a subdirectory
+.Directory RCS
+if it exists.  To avoid file name conflicts, \fIRCS\fP\/ appends the characters
+\fI,v\fP\/ to the RCS file, so the working file
+.File -n main.c \&
+would correspond to the RCS file
+.File -n main.c,v .
+For more details of \fIRCS\fP, see the man page.
+.P
+\fICVS\fP\/ is an extension to \fIRCS\fP\/ that allows concurrent access,
+making it more suitable for projects involving more than one person.  Unlike
+\fIRCS\fP, it stores its RCS files in a separate directory hierarchy, called a
+\fIrepository\fP.  Each directory in the working tree contains a subdirectory
+.Directory CVS
+with information on the location of the repository, the revisions of the working
+files and a tag if the revision isn't on the trunk.
+.P
+If you're a serious developer, there are a number of advantages to keeping a
+copy of the repository.  If you're a casual user, it's probably overkill.
 .H2 "FreeBSD releases"
-.X "FreeBSD releases"
-.Pn release-tags
-The three ``latest'' versions of FreeBSD are aimed at different groups of
-people.
+There are four main versions of FreeBSD, each intended for use by different
+people:
 .H3 "FreeBSD-RELEASE"
 .X "FreeBSD-RELEASE"
-\fIFreeBSD-RELEASE\fP\| is the latest version of FreeBSD which has been released
-for general use.  It contains as many new features as are consistent with
-stability.  It has been through extensive testing.  You can get it on CD-ROM.
-FreeBSD-RELEASEs are given a release number which uniquely identifies them, such
-as 4.5.  There are three or four releases a year.
+\fIFreeBSD-RELEASE\fP\/ is the latest version of FreeBSD that has been released
+for general use.  It contains those new features that are stable, and it has
+been through extensive testing.  You can get it on CD-ROM.  FreeBSD-RELEASEs are
+given a release number that uniquely identifies them, such as 5.0.  There are
+three or four releases a year.  A new branch is made for each release of
+FreeBSD.
 .H3 "FreeBSD-STABLE"
 .X "FreeBSD-STABLE"
-\fIFreeBSD-STABLE\fP\| is a version of FreeBSD-RELEASE to which all possible bug
-fixes have been applied, in order to make it as stable as possible.  Fixes are
-made on a daily basis.  It is based on the same source branch as
+\fIFreeBSD-STABLE\fP\/ is an updated version of FreeBSD-RELEASE to which all
+possible bug fixes have been applied, to make it as stable as possible.  Fixes
+are made on a daily basis.  It is based on the same source branch as
 FreeBSD-RELEASE, so it has all the features and fewer bugs.  It may contain
 additional features, but new features are tested in the \f(CW-CURRENT\fP branch
 first.
 .P
 Due to the frequent updates, FreeBSD-STABLE is not available on CD-ROM.
+.H3 "Security fix releases"
+Despite the name, FreeBSD-STABLE is subject to some problems.  Every change to a
+source tree has the potential to go wrong.  In many cases, you're more
+interested in keeping your system running than you are in getting minor bug
+fixes.  FreeBSD also maintains a second ``stable'' branch consisting of the
+release and only very important bug fixes, including security updates.  This
+branch does not have a well-defined name, but it's generally referred to as the
+\fIsecurity branch\fP\/.
 .H3 "FreeBSD-CURRENT"
 .X "FreeBSD-CURRENT"
 .X "/usr/src/Makefile"
-\fIFreeBSD-CURRENT\fP\| is the very latest version of FreeBSD, still under
-development.  All new development work is done on this branch of the tree.
+\fIFreeBSD-CURRENT\fP\/ is the very latest version of FreeBSD, located on the
+trunk of the tree.  All new development work is done on this branch of the tree.
 FreeBSD-CURRENT is an ever-changing snapshot of the working sources for FreeBSD,
 including work in progress, experimental changes and transitional mechanisms
 that may or may not be present in the next official release of the software.
@@ -56,45 +141,52 @@
 times when the sources are uncompilable, or when the system crashes frequently.
 The problems are always resolved, but others can take their place.  On occasion,
 keeping up with FreeBSD-CURRENT can be a full-time business.  If you use
--CURRENT, you should be prepared to spend a lot of time keeping the system
-running.  The following extract from the RCS log file for
-\fI/usr/src/Makefile\fP\| should give you a feel for the situation:
-.in +.2i
-.sp
-.ft I
+\f(CW-CURRENT\fP, you should be prepared to spend a lot of time keeping the
+system running.  The following extract from the RCS log file for
+.File /usr/src/Makefile
+should give you a feel for the situation:
+.Pn hooboy .
+.Dx
+$ \f(CBcvs log Makefile\fP
+\&\fI...\fP\/
 revision 1.152
-.br
+date: 1997/10/06 09:58:11;  author: jkh;  state: Exp;  lines: +41 -13
 Hooboy!
 
-Did I ever spam this file good with that last commit.  Despite 3 reviewers, we
-still managed to revoke the eBones fixes, TCL 8.0 support, libvgl and a host of
-other new things from this file in the process of parallelizing the Makefile.
-DOH!  I think we need more pointy hats - this particular incident is worthy of a
-small children's birthday party's worth of pointy hats. ;-)
-
-I certainly intend to take more care with the processing of aged diffs in the
-future, even if it does mean reading through 20K's worth of them.  I might also
-be a bit more careful about asking for more up-to-date changes before looking at
-them. ;)
-.ft
-.in
+Did I ever spam this file good with that last commit.  Despite 3
+reviewers, we still managed to revoke the eBones fixes, TCL 8.0 support,
+libvgl and a host of other new things from this file in the process of
+parallelizing the Makefile.  DOH!   I think we need more pointy hats - this
+particular incident is worthy of a small children's birthday party's worth of
+pointy hats. ;-)
+
+I certainly intend to take more care with the processing of aged diffs
+in the future, even if it does mean reading through 20K's worth of them.
+I might also be a bit more anal about asking for more up-to-date changes
+before looking at them. ;)
+.De
+This example also shows the list of the symbolic names for this file, and their
+corresponding revision numbers.  There is no symbolic name for \f(CW-CURRENT\fP,
+because it is located on the trunk.  That's the purpose of the line
+\f(CWhead:\fP, which shows that at the time of this example, the
+\f(CW-CURRENT\fP revision of this file was 1.270.
 .P
-So why use -CURRENT?  The main reasons are:
+So why use \f(CW-CURRENT\fP?  The main reasons are:
 .Ls B
 .LI
-You yourself might be working on some part of the source tree.  Keeping
+You might be doing development work on some part of the source tree.  Keeping
 ``current'' is an absolute requirement.
 .LI
-You may be an active tester, which imples that you're willing to spend time
-working through problems in order to ensure that FreeBSD-CURRENT remains as sane
-as possible.  You may also wish to make topical suggestions on changes and the
+You may be an active tester, which implies that you're willing to spend time
+working through problems to ensure that FreeBSD-CURRENT remains as sane as
+possible.  You may also wish to make topical suggestions on changes and the
 general direction of FreeBSD.
 .LI
 You may just want to keep an eye on things and use the current sources for
 reference purposes.
 .Le
 People occasionally have other reasons for wanting to use FreeBSD-CURRENT.  The
-following are \fInot\fP\| good reasons:
+following are \fInot\fP\/ good reasons:
 .Ls B
 .LI
 They see it as a way to be the first on the block with great new FreeBSD
@@ -103,141 +195,110 @@
 unstable.
 .LI
 They see it as a quick way of getting bug fixes.  In fact, it's a way of
-\fItesting\fP\| bug fixes.  Bug fixes will be retrofitted into the -STABLE
+\fItesting\fP\/ bug fixes.  Bug fixes will be retrofitted into the -STABLE
 branch as soon as they have been properly tested.
 .LI
 They see it as the newest officially supported release of FreeBSD.  This is
-incorrect: FreeBSD-CURRENT is \fInot\fP\| officially supported.  The support is
+incorrect: FreeBSD-CURRENT is \fInot\fP\/ officially supported.  The support is
 provided by the users.
 .Le
+If you do decide to use \f(CW-CURRENT\fP, read the suggestions on page
+.Sref \*[current] .
 .H4 "Snapshots"
 .X "snapshot"
-FreeBSD-CURRENT \fIis\fP\| available in the form of ISO (CD-ROM) images.
-Several times a year, at irregular intervals when the tree is relatively stable,
-the release team makes a \fIsnapshot\fP\| of the repository and the -CURRENT
-source tree.  This is a possible alternative to on-line updates if you don't
-want the absolute latest version of the system.
-.H2 "The repository"
-.X "repository, cvs"
-.X "cvs, repository"
-.X "CVS"
-.X "Revision Control System"
-.X "RCS"
-The \fIrepository\fP\| is the home of all FreeBSD releases.  As we have seen, it
-is maintained by \fICVS\fP, which is a system built on top of the \fIRevision
-Control System\fP, or \fIRCS\fP.
-.P
-.X "trunk, cvs"
-.X "cvs, trunk"
-.X "branch, cvs"
-.X "cvs, branch"
-The repository is a duplicate of the source tree with copies of each file in the
-source tree.  It modifies the names by appending the suffix \fI,v\fP\|: for
-example, \fImain.c\fP\| in the source tree becomes \fImain.c,v\fP\| in the
-repository.  These files contain a copy of the most recent version of the file,
-along with a lot of information about how to create older versions of the source
-from the current version.  Each version has an identification which is either in
-two parts (for example, version 1.3), or in four parts (for example, version
-1.2.1.4).  The two-part versions are said to be on the \fItrunk\fP\| of the
-tree, whereas the four-part versions are on \fIbranches\fP.  In FreeBSD, the
-trunk is the -CURRENT version.
-.P
-.X "symbolic names, cvs"
-In addition to the numeric identifiers, each of which relates only to a single
-file, RCS allows you to attach \fIsymbolic names\fP\| to specific revisions.
-FreeBSD uses these to indicate the revisions corresponding to a particular
-release.  For example, in the directory \fI/usr/src/sys/kern\fP, version 1.13 of
-\fIkern_clock.c\fP, version 1.12 of \fIkern_fork.c\fP\| and version 1.21.4.1 of
-\fIkern_exec.c\fP\| participate in \f(CWRELENG_2_1_0_RELEASE\fP.  For more
-details of \fIRCS\fP, see the man page.
-.P
-If you're a serious developer, there are a number of advantages to keeping a
-copy of the repository.  If you're a casual user, it's probably overkill.
-.H2 "Getting updates from the net"
-.X "getting updates from the net"
-.X "updates, getting from the net"
+FreeBSD-CURRENT \fIis\fP\/ available in the form of ISO (CD-ROM) images.  From
+time to time, at irregular intervals when the tree is relatively stable, the
+release team makes a \fIsnapshot\fP\/ release from the \f(CW-CURRENT\fP source
+tree.  They are also available on CD-ROM from some vendors; check the online
+handbook for details.  This is a possible alternative to online updates if you
+don't want the absolute latest version of the system.
+.H2 "Getting updates from the Net"
 There are a number of possibilities to keep up with the daily modifications to
 the source tree.  The first question is: how much space do you want to invest in
 keeping the sources?  Table \*[source-tree-space]
 .\" XXX.pageref \*[source-tree-space-page] "on page \*[source-tree-space-page]"
-shows the space required by different parts of the sources.
+shows the approximate space required by different parts of the sources.  Note
+that the repository keeps growing faster than the source tree, because it
+includes all old revisions as well.
 .br
-.DF
-.fam G
+.Table-heading "Approximate source tree sizes"
+.P
 .fi
-.TB "Approximate source tree sizes"
 .TS
-box,center,tab(#) ;
-| l | r | .
+tab(#) ;
+ l | r  .
 Component#Size (MB)
-=
-Repository \fIsrc/sys\fP\|#250
-Repository \fIsrc\fP\|#1000
-Repository \fIports\fP\|#300
-Source tree \fI/usr/src/sys\fP\|#110
-Source tree \fI/usr/src\fP\|#450
-Source tree \fI/usr/ports\fP\|#200
-Object tree \fIsrc\fP\|#160
+_
+Repository \fIsrc/sys\fP\/#250
+Repository \fIsrc\fP\/#1000
+Repository \fIports\fP\/#300
+Source tree \fI/usr/src/sys\fP\/#110
+Source tree \fI/usr/src\fP\/#450
+Source tree \fI/usr/ports\fP\/#200
+Object tree \fI/usr/obj\fP\/#160
 .TE
 .Tn source-tree-space
-.DE
 .sp 1.5v
-The size of \fI/usr/src/sys\fP\| includes the files involved in a single kernel
-build.  This changes the size of \fI/usr/src\fP\| as well, of course.
-Similiarly, the size of \fI/usr/ports\fP\| includes a few ports.  It will, of
-course, grow extremely large (several gigabytes) if you start porting all
-available packages.
+The size of
+.Directory /usr/src/sys
+includes the files involved in a single kernel build.  You can remove the entire
+kernel build directory, but if you want to be able to analyze a panic dump, you
+should keep the
+.File kernel.debug
+file in the kernel build directory.  This changes the size of
+.Directory /usr/src
+as well, of course.
+The other object files get built in the directory
+.Directory /usr/obj .
+Again, you can remove this directory tree entirely if you want, either with the
+.Command rm
+command or with \f(CWmake clean\fP.  Similarly, the size of
+.Directory /usr/ports
+includes a few ports.  It will, of course, grow extremely large (many gigabytes)
+if you start porting all available packages.
 .P
 If you're maintaining multiple source trees (say, for different versions), you
 still only need one copy of the repository.
 .P
-.H3 "How to get the updates"
-.X "CVSup, command"
-.X "command, CVSup"
-.X "CTM, command"
-.X "command, CTM"
-You also have the choice of how to get the updates.  Normally you use
-\fICVSup\fP\| to update your repository.  If you have a marginal connection to
-the Internet, you may find \fICTM\fP\| more useful.  We'll look at both in the
-following sections.
 .H3 "CVSup"
 .Pn CVSup
-.X "CVSup, command"
-.X "command, CVSup"
-.X "cron, command"
-.X "command, cron"
-\fICVSup\fP\| is a software package which distributes updates to the repository.
-You can run the client at regular intervals\(emfor example, with \fIcron\fP\|
+.X "cvsup, command"
+\fICVSup\fP\/ is a software package that distributes updates to the repository.
+You can run the client at regular intervals\(emfor example, with
+.Daemon cron
 (see page \*[cron]) to update your repository.
 .P
-To get started with \fICVSup\fP\|, you need the following:
+To get started with \fICVSup\fP\/, you need the following:
 .Ls B
 .LI
 A source tree or repository, which doesn't have to be up to date.  This is not
-absolutely necessary, but the initial setup will be much faster if you do it
-this way.
+absolutely necessary, but the initial setup will be faster if you do it this
+way.
 .LI
-.X "pkg_add, command"
-.X "command, pkg_add"
-A copy of the \fIcvsup\fP\| program.  Install this with \fIpkg_add\fP\| from the
-CD-ROM (currently \fI/cdrom/packages/All/cvsup-16.1e.tgz\fP\|; the suffix may
-change in future releases).
+A copy of the
+.Command cvsup
+program.  Install it with
+.Command pkg_add
+from the CD-ROM
+.File -n ( /cdrom/packages/Latest/cvsup.tbz ).
 .LI
 .X "cvsupfile"
-A \fIcvsupfile\fP, a command file for \fIcvsup\fP.  We'll look at this below.
+A \fIcvsupfile\fP, a command file for
+.Command cvsup .
+We'll look at this below.
 .LI
 .X "mirror site"
-A \fImirror site\fP\| from which you can load the software.  We'll discuss this
-below as well.
+A \fImirror site\fP\/ from which you can load or update the repository.  We'll
+discuss this below as well.
 .Le
-The \fIcvsupfile\fP\| contains a description of the packages you want to
+The \fIcvsupfile\fP\/ contains a description of the packages you want to
 download.  You can find all the details in the online handbook, but the
 following example shows a reasonably normal file:
 .Dx
 *default release=cvs
 *default host=cvsup9.freebsd.org
 *default base=/src/cvsup
-*default prefix=/src/ncvs
+*default prefix=/home/ncvs
 *default delete
 *default use-rel-suffix
 *default compress
@@ -245,433 +306,319 @@
 ports-all
 doc-all
 .De
-The lines starting with \f(CW*default\fP specify default values; the lines which
-do not are collections which you want to track.  This file answers these
-implicit questions:
+The lines starting with \f(CW*default\fP specify default values; the lines that
+do not are collections that you want to track.  This file answers these implicit
+questions:
 .Ls B
 .LI
-.X "collections, CVSup"
-.X "CVSup, collections"
+.X "collection, CVSup"
+.X "cvsup, collection"
 Which files do you want to receive?  These are the names of the
-\fIcollections\fP\| in the last five lines: all of the sources, all of the
-ports, and all of the documentation.
+\fIcollections\fP\/ in the last three lines: all of the sources, ports and
+documentation.
 .LI
 Which versions of them do you want?  By default, you get updates to the
 repository.  If you want a specific version, you can write:
 .Dx
-*default tag=\fIversion\fP\|
+*default tag=\fIversion\fP\/
 .De
-\fIversion\fP\| is one of the tags we saw on page \*[release-tags], or \f(CW.\fP
-(a period) to represent the -CURRENT version.
+\fIversion\fP\/ is a \fIrelease tag\fP\/ that identifies the version you want,
+or \f(CW.\fP (a period) to represent the \f(CW-CURRENT\fP version.  We'll
+discuss release tags on page
+.Sref \*[release-tags] .
 .P
 Alternatively, you might ask for a version as of a specific date.  For example:
 .Dx
 *default date=97.09.13.12.20
 .De
-This would specify that you want \fIthe version\fP\| as it was on 13 September
-1997 at 12:20.  In this case, \fIversion\fP\| defaults to \f(CW.\fP.
+This would specify that you want \fIthe version\fP\/ as it was on 13 September
+1997 at 12:20.  In this case, \fIversion\fP\/ defaults to \f(CW.\fP (a period).
 .LI
 Where do you want to get them from?  Two parameters answer this question:
 \f(CWhost=cvsup9.freebsd.org\fP specifies the name of the host from which to
-load the files, and \f(CWrelease=cvs\fP specifies to use the \fIcvs\fP\|
-release.  The \fIrelease\fP\| option is obsolescent, but it's a good idea to
+load the files, and \f(CWrelease=cvs\fP specifies to use the \fIcvs\fP\/
+release.  The \fIrelease\fP\/ option is obsolescent, but it's a good idea to
 leave it in there until it is officially removed.
 .LI
 Where do you want to put them on your own machine?  This question is answered by
-the line \f(CW*default prefix=/src/ncvs\fP.  Since we're tracking the repository
-in this example, this is the name of the repository.  If we were tracking a
-particular release, we would use \f(CW*default prefix=/usr\fP.  Since the
-collections are called \fIdoc\fP, \fIports\fP\| and \fIsrc\fP, we refer to the
-parent directory in each case.
+the line \f(CW*default prefix=/home/ncvs\fP.  We're tracking the repository in
+this example, so this is the name of the repository.  If we were tracking a
+particular release, we would use \f(CW*default prefix=/usr\fP.  The collections
+are called \fIdoc\fP, \fIports\fP\/ and \fIsrc\fP, so we refer to the parent
+directory in each case.
 .LI
 Where do you want to put your status files?  This question is answered by the
 line \f(CW*default base=/src/cvsup\fP.
 .Le
 In addition, the file contains three other lines.  \f(CW*default delete\fP means
-that \fIcvsup\fP\| may delete files where necessary.  Otherwise you run the risk
-of accumulating obsolete files.  \f(CW*default compress\fP enables compression
-of the data transmitted, and \f(CW*default use-rel-suffix\fP specifies how
-\fIcvsup\fP\| should handle list files.  It's not well-documented, but it's
-necessary.  Don't worry about it.
+that
+.Command cvsup
+may delete files where necessary.  Otherwise you run the risk of accumulating
+obsolete files.  \f(CW*default compress\fP enables compression of the data
+transmitted, and \f(CW*default use-rel-suffix\fP specifies how
+.Command cvsup
+should handle list files.  It's not well-documented, but it's necessary.  Don't
+worry about it.
 .H3 "Which CVSup server?"
-.X "which CVSup server?"
-.X "CVSup, which server?"
+.X "which cvsup server?"
+.X "cvsup, which server?"
 In this example, we've chosen one of the backup US servers,
 \fIcvsup9.FreeBSD.org\fP.  In practice, this may not be the best choice.  A
 large number of servers are spread around the world, and you should choose the
 one topographically closest to you.  This isn't the same thing as being
 geographically closest\(emI live in Adelaide, South Australia, and some ISPs in
-the same city are further away on the net than many systems in California.  Look
-in the appendix \fIObtaining FreeBSD\fP\| in the online handbook for an
-up-to-date list.
-.H3 "Running \fIcvsup\fP\|"
-.X "running cvsup"
+the same city are further away on the Net than many systems in California.  Look
+on the web site
+.URI http://www.FreeBSD.org
+for an up-to-date list.
+.H3 "Running \fIcvsup\fP\/"
 .X "cvsup, running"
-.X "/root/crontab"
-The handbook recommends running \fIcvsup\fP\| via a GUI interface.  I don't.
-\fIcvsup\fP\| is a typical candidate for a \fIcron\fP\| job.  I rebuild the
--CURRENT tree every morning at 3 am.  To do so, I have the following entry in
-\fI/root/crontab\fP\|:
+.X "cvsupfile, file"
+.X "file, cvsupfile"
+.Command cvsup
+is a typical candidate for a \fIcron\fP\/ job.  I rebuild the \f(CW-CURRENT\fP
+tree every morning at 3 am.  To do so, I have the following entry in
+.File /root/crontab \/:
 .Dx
 # Get the latest and greatest FreeBSD stuff.
 0 3 * * * ./extract-updates
 .De
-The file \fI/root/extract-updates\fP\| contains, amongst other things,
+.ne 6v
+The file
+.File /root/extract-updates
+contains, amongst other things,
 .Dx
 cvsup -g -L2 /src/cvsup/cvs-cvsupfile
 .De
-\fI/src/cvsup/cvs-cvsupfile\fP\| is the name of the \fIcvsupfile\fP\| we looked
-at above.  The other parameters to \fIcvsup\fP\| specify \fInot\fP\| to use the
-GUI (\f(CW-g\fP), and \f(CW-L2\fP specifies to produce moderate detail about the
-actions being performed.
-.H3 "Other possible cvsupfiles"
-The example \fIcvsupfile\fP\| above is useful if you're maintaining a copy of
+.File -n /src/cvsup/cvs-cvsupfile
+is the name of the \fIcvsupfile\fP\/ we looked at above.  The other parameters
+to
+.Command cvsup
+specify \fInot\fP\/ to use the GUI (\f(CW-g\fP), and \f(CW-L2\fP specifies to
+produce moderate detail about the actions being performed.
+.H3 "Getting individual releases"
+The example \fIcvsupfile\fP\/ above is useful if you're maintaining a copy of
 the repository.  If you just want to maintain a copy of the sources of one
-version, say 4.5, use the following file instead:
+version, say Release 5.0, use the following file instead:
 .Dx
-*default tag=RELENG_4_5_RELEASE
+*default tag=RELENG_5_0_0_RELEASE
 *default release=cvs
 *default host=cvsup9.freebsd.org
-*default base=/usr				\fIfor /usr/doc, /usr/ports, /usr/src\fP\|
-*default prefix=/src/ncvs
+*default base=/usr                              \fIfor /usr/doc, /usr/ports, /usr/src\fP\/
+*default prefix=/home/ncvs
 *default delete
 *default use-rel-suffix
 *default compress
 src-all 
-ports-all
-doc-all
-.De
-.X "cvs-crypto, collection"
-.X "collection, cvs-crypto"
-.X "cvsup.internat.freebsd.org"
-One collection causes special problems: \fIcvs-crypto\fP\| contains
-cryptographic software.  Until recently, exporting this software from the USA
-was subject to strict export restrictions, and it's not clear that these
-restrictions might not be reimposed.  To be on the safe side, don't load them
-from a US site if you are located outside the USA.  It \fIis\fP\| legal to
-import them into the USA, but once you have done so, you may not be allowed to
-re-export them.  If you are in the USA, or if you are loading from
-\fIcvsup.internat.freebsd.org\fP, you can also add the following line to the end
-of either \fIcvsupfile\fP:
-.Dx
-cvs-crypto
-.De
-Otherwise create a second \fIcvsupfile\fP\| to load from
-\fIcvsup.internat.freebsd.org\fP\|: each \fIcvsupfile\fP\| file may refer to
-only one host.  Write:
-.Dx
-*default tag=RELENG_4_5_RELEASE
-*default release=cvs
-*default host=cvsup.internat.freebsd.org	\fIthe international security mirror\fP\|
-*default base=/usr				\fIfor /usr/doc, /usr/ports, /usr/src\fP\|
-*default prefix=/src/ncvs
-*default delete
-*default use-rel-suffix
-*default compress
-cvs-crypto
-.De
-.sp -1v
-.H3 "CTM"
-.X "ctm, command"
-.X "command, ctm"
-If your Internet connection isn't good enough for \fICVSup\fP\|, \fICTM\fP\|
-might be for you.  \fICTM\fP\| distributes updates by mail.  To get started, do
-the following:
-.Ls B
-.LI
-Send mail to \f(CWmajordomo@FreeBSD.org\fP with an empty subject and a body
-containing the lines
-.Dx
-subscribe ctm-announce@FreeBSD.org
-subscribe ctm-src-cur@FreeBSD.org
-.De
-\f(CWctm-src-cur\fP is the list on which \fICTM\fP\| distributes the deltas for
--CURRENT.  There are a number of other mailing lists, but their purpose is not
-well documented.
-.LI
-.X "ctm, command"
-.X "command, ctm"
-.X "ctm_rmail, command"
-.X "command, ctm_rmail"
-Make sure you have the programs \fIctm\fP\| and \fIctm_rmail\fP\|.  They're part
-of the FreeBSD distribution, and should be in \fI/usr/sbin\fP.
-.LI
-.Pn cvs-ftp
-.X "base delta, ctm"
-.X "ctm, base delta"
-Get a source tree.  Unlike \fICVSup\fP\|, this is \fInot\fP\| optional.  You can
-get one in the form of a \fIbase delta\fP\| from
-\fIftp://ftp.FreeBSD.org/pub/FreeBSD/CTM\fP.  In this directory you will find a
-number of choices: \fIcvs-cur\fP, \fIports-cur\fP\| and \fIsrc-cur\fP\| are the
--CURRENT directories, and \fIsrc-2.1\fP, \fIsrc-2.2\fP\| etc. are the release
-directories.  In any of these you will find file names like:
-.Dx
--r--r--r--  1 root  wheel     37754436 Aug  9 11:22 src-cur.0400xEmpty.gz
--r--r--r--  1 root  wheel         8740 Aug 10 02:45 src-cur.0401.gz
--r--r--r--  1 root  wheel        12552 Aug 11 02:46 src-cur.0402.gz
--r--r--r--  1 root  wheel        13353 Aug 11 18:45 src-cur.0403.gz
--r--r--r--  1 root  wheel         3538 Aug 12 10:39 src-cur.0404.gz
--r--r--r--  1 root  wheel        10973 Aug 13 02:46 src-cur.0405.gz
--r--r--r--  1 root  wheel         8556 Aug 13 18:40 src-cur.0406.gz
 .De
-As you can see from its size, the first of these files,
-\fIsrc-cur.0400xEmpty.gz\fP, is a \fIbase delta\fP.  The remaining files
-represent updates, called \fIdeltas\fP\| in \fICTM\fP\| terminology.  Get the
-newest of the base deltas, since you need to apply all subsequent deltas to it.
-.LI
-Decide on two directories:
-.Ls N
-.LI
-A directory in which to store the deltas.  Make sure you have plenty of space
-here.  For the sake of example, call it \fI/src/ctm/0400\fP.  It's a good idea,
-but not essential, to keep multiple directories, each with 100 deltas.  Every
-time the number increments by 100, create a new directory.  For example, the
-next directory could be \fI/src/ctm/0500\fP.  This speeds up the operation of
-\fIctm\fP.
-.LI
-A directory where you're going to maintain the tree.  This is the same
-consideration as for \fICVSup\fP\|: if you're maintaining a repository, it
-should have a name like \fI/src/ncvs\fP.  Otherwise it will be \fI/usr/doc\fP,
-\fI/usr/ports\fP\| or \fI/usr/src\fP.
-.Le
-Now you're ready to go.  To extract your deltas, do:
-.Dx
-# \f(CBcd /usr/src\fP
-# \f(CBctm -v -v /src/ctm/0400/*\fP
-Warning: .ctm_status not found.
-Working on </src/ctm/0400/src-2.2.0400xEmpty.gz>
-Expecting Global MD5 <557c6f7601490a32d89114361beebdca>
-Reference Global MD5 <557c6f7601490a32d89114361beebdca>
-> FM .ctm_status
-> FM COPYRIGHT
-> FM Makefile
-> FM README
-> DM bin
-> FM bin/Makefile
-> FM bin/Makefile.inc
-> DM bin/cat
-> FM bin/cat/Makefile
-\fI\&... etc\fP\|
-> FM usr.sbin/zic/zic.c
-All done ok
-Working on </src/ctm/0400/src-2.2.0401.gz>
-Expecting Global MD5 <690bc0bbe90d846566f2af1dcd7cc25c>
-Reference Global MD5 <690bc0bbe90d846566f2af1dcd7cc25c>
-> FS .ctm_status
-> FN usr.bin/tip/tip/cmds.c
-\fI\&... etc\fP\|
-> FN usr.sbin/sendmail/cf/cf/hub.mc
-All done ok
-Working on </src/ctm/0400/src-2.2.0402.gz>
-Expecting Global MD5 <0941d8a04d828eef3ba3bbc0bd400d89>
-Reference Global MD5 <0941d8a04d828eef3ba3bbc0bd400d89>
-> FS .ctm_status
-> FN sbin/shutdown/shutdown.c
-\fI\&... etc\fP\|
-> FN usr.sbin/lpr/lpd/lpd.c
-All done ok
-Exit(0)
-.De
-The first time round, this will extract your base delta and then all other
-deltas you might have collected.  \fIctm\fP\| notes the last delta it extracts,
-so next time it will start with the next higher number.  This is the reason why
-it's a good idea to keep separate directories for each 100 deltas, so that
-\fIctm\fP\| doesn't have to examine all the deltas to find out which need to be
-applied.
-.Le
-.H3 "Getting deltas by mail"
-.X "getting deltas by mail"
-.X "deltas, getting by mail"
-.X "ctm, command"
-.X "command, ctm"
-.X "ctm_rmail, command"
-.X "command, ctm_rmail"
-When you receive deltas by mail, you will first need to convert them into the
-format used by \fIctm\fP.  \fIctm_rmail\fP\| performs this job.  First, save the
-messages into a folder, say \fIctm\fP, then enter:
-.Dx
-# \f(CBcd /src/ctm/0400\fP
-# \f(CBctm_rmail -p ~/Mail/ctm -d .\fP
-.De
-This assumes you are using a standard mailer which keeps its folders in the
-subdirectory \fIMail\fP\| of your home directory (\fI~/Mail\fP\|).
-.P
-\fIctm_rmail\fP\| will extract the files no matter what sequence they are
-in\(emthey will seldom be in the correct sequence.  Often you will find that a
-large delta is split into multiple parts, and that only some of them have arrive
-at any particular occasion.  This does not confuse \fIctm_rmail\fP\| either:
-when they have all arrived, it will create a correct delta.
-.H3 "Getting deltas with \fIftp\fP\|"
-.X "getting deltas with \fIftp\fP\|"
-.X "deltas, getting with \fIftp\fP\|"
-As we saw
-.pageref \*[cvs-ftp] "above on page \*[cvs-ftp]," above,
-you can also get deltas with \fIftp\fP.  You may need to do this, for example,
-if a mail message gets lost.  Proceed as described above.
+Be careful with tags.  They must exist in the repository, or
+.Command cvsup
+will replace what you have with nothing: it will delete all the files.  In our
+original
+.File -n cvsupfile ,
+we had two additional sets, \f(CWports-all\fP and \fIdoc-all\fP.  These sets
+don't have the same release tags, so if you left them in this file, you would
+lose all the files in the
+.Directory /usr/doc
+and
+.Directory /usr/ports
+directory hierarchies.
 .H2 "Creating the source tree"
 .X "creating the source tree"
 .X "source tree, creating"
 If you're tracking the repository, you're not finished yet.  Once you have an
 up-to-date repository, the next step is to create a source tree.  By default,
-the source tree is called \fI/usr/src\fP, though it's very common for
-\fI/usr/src\fP\| to be a symbolic link to a source tree on a different file
-system.  You create the tree with \fIcvs\fP.
-.P
-Before you check anything out with \fIcvs\fP, you need to know:
+the source tree is called
+.Directory /usr/src ,
+though it's very common for
+.Directory /usr/src
+to be a symbolic link to a source tree on a different file system.  You create
+the tree with
+.Command cvs .
+.P
+.ne 5v
+Before you check anything out with
+.Command cvs ,
+you need to know:
 .Ls N
 .LI
-What do you want to check out?  You specify this by the name of a directory (for
-example, \fIsrc/sys\fP\|), or with the keyword \f(CWworld\fP.  Note that there
-are three top-level directories: \fIdoc\fP, \fIports\fP\| and \fIsrc\fP.
+What do you want to check out?  You specify this with a module name, which
+usually corresponds with a directory name (for example, \fIsrc\fP\/).  There are
+a number of top-level modules, including \fIdoc\fP, \fIports\fP, \fIsrc\fP\/ and
+\fIwww\fP.
 .LI
 Which version do you want to check out?  By default, you get the latest version,
 which is FreeBSD-CURRENT.  If you want a different version, you need to specify
 its \fItag\fP.
 .LI
 Possibly, the date of the last update that you want to be included in the
-checkout.  If you specify this date, \fIcvs\fP\| ignores any more recent
-updates.  This option is often useful when somebody discovers a recently
-introduced bug in -CURRENT: you check out the modules as they were before the
-bug was introduced.  You specify the date with the \f(CW-D\fP option, for
-example \f(CW-D "10 December 1997"\fP.
+checkout.  If you specify this date,
+.Command cvs
+ignores any more recent updates.  This option is often useful when somebody
+discovers a recently introduced bug in \f(CW-CURRENT\fP: you check out the
+modules as they were before the bug was introduced.  You specify the date with
+the \f(CW-D\fP option, as we'll see below.
 .Le
-.H3 "The tags"
-.X "cvs tag"
-.X "tag, cvs"
-FreeBSD releases contain two, three or four numbers separated by periods.  Each
+.SPUP
+.H3 "Release tags"
+.Pn release-tags
+.X "CVS, tag"
+.X "tag, CVS"
+FreeBSD identifies releases with two or more numbers separated by periods.  Each
 number represents a progressively smaller increment in the functionality of the
 release.  The first number is the base release of FreeBSD.  The number is
-incremented only when significant functionality is added to the system.  For
-example, release 1 of FreeBSD was based on the Net/2 tapes from Berkeley, which
-were a heavily modified 4.3BSD.  Release 2 bases on 4.4BSD.  Release 3 includes
-significant new development, particularly in the areas of file system and memory
-management.
-.P
-The second number represents a less significant, but still important difference
-in the functionality, and the third number represents a minor release.  The
-fourth number is only used when a significant bug requires re-release of an
-otherwise unchanged release.
+incremented only when significant functionality is added to the system.  The
+second number represents a less significant, but still important difference in
+the functionality, and the third number is only used when a significant bug
+requires rerelease of an otherwise unchanged release.  Before Release 3 of
+FreeBSD, a fourth number was sometimes also used.
 .P
 Tags for released versions of FreeBSD follow the release numbers.  For release
-\fIx\fP.\fIy\fP.\fIz\fP\| you would look for the tag
-\f(CWRELENG_\fIx\fP\|_\fIy\fP\|_\fIz\fP\_RELEASE\fR.  For example, to get the
-current state of the FreeBSD 4.5 source tree, you would look for the tag
-\f(CWRELENG_4_5_RELEASE\fP.
+\fIx\fP.\fIy\fP.\fIz\fP\/ you would look for the tag
+\f(CWRELENG_\|\fIx\fP\/_\|\fIy\fP\/_\|\fIz\fP\/_RELEASE\fR.  For example, to get
+the current state of the FreeBSD 5.0 source tree, you would look for the tag
+\f(CWRELENG_5_0_0_RELEASE\fP.
+.P
+Tags for the -STABLE branch are simpler: they just have the release number, for
+example \f(CWRELENG_4\fP.  The security branch has an additional number, for
+example \f(CWRELENG_4_7\fP.
 .P 
 Some tags diverge from this scheme.  In particular, \f(CWCSRG\fP and
 \f(CWbsd_44_lite\fP both refer to the original 4.4BSD sources from Berkeley.  If
 you feel like it, you can extract this source tree as well.
 .P
+.ne 5v
 To find out what tags are available, do:
 .Dx
 # \f(CBcd $CVSROOT/src\fP
-# \f(CBcvs log Makefile | less\fP
-
+# \f(CBrlog Makefile,v | less\fP
+RCS file: /home/ncvs/src/Makefile,v
 RCS file: /home/ncvs/src/Makefile,v
 Working file: Makefile
-head: 1.246
+head: 1.270
 branch:
 locks: strict
 access list:
 symbolic names:
-        RELENG_4_4_0_RELEASE: 1.234.2.10
-        RELENG_4_4: 1.234.2.10.0.2
-        RELENG_4_4_BP: 1.234.2.10
+        RELENG_5_0_0_RELEASE: 1.271             \fI5.0-RELEASE\fP\/
+\&...
+        RELENG_4_7_0_RELEASE: 1.234.2.18        \fI4.7-RELEASE\fP\/
+        RELENG_4_7: 1.234.2.18.0.2              \fI4.7 security fixes only\fP\/
+        RELENG_4_7_BP: 1.234.2.18               \fIbranch point for 4.7\fP\/
+        RELENG_4_6_2_RELEASE: 1.234.2.12        \fI4.6.2-RELEASE\fP\/
+        RELENG_4_6_1_RELEASE: 1.234.2.12        \fI4.6.1-RELEASE\fP\/
+        RELENG_4_6_0_RELEASE: 1.234.2.12        \fI4.6-RELEASE\fP\/
 \&...
-        RELENG_2_2_5_RELEASE: 1.109.2.19
-        RELENG_2_2_2_RELEASE: 1.109.2.4
-        RELENG_2_2_1_RELEASE: 1.109.2.2
-        RELENG_2_2_0_RELEASE: 1.109.2.2
-        RELENG_2_1_7_RELEASE: 1.57.4.19
-        RELENG_2_1_6_1_RELEASE: 1.57.4.19
-        RELENG_2_1_6_RELEASE: 1.57.4.19
-        RELENG_2_2: 1.109.0.2
-        RELENG_2_2_BP: 1.109
-        RELENG_2_1_5_RELEASE: 1.57.4.17
-        RELENG_2_1_0_RELEASE: 1.57.4.8
-        RELENG_2_1_0: 1.57.0.4
-        RELENG_2_1_0_BP: 1.57
-        RELENG_2_0_5_RELEASE: 1.57
-        RELENG_2_0_5: 1.57.0.2
-        RELENG_2_0_5_BP: 1.57
-        RELENG_2_0_5_ALPHA: 1.56
-        RELEASE_2_0: 1.30
+        RELENG_4: 1.234.0.2                     \fI4-STABLE\fP\/
+\&...
+        RELEASE_2_0: 1.30                       \fI2.0-RELEASE\fP\/
         BETA_2_0: 1.30
         ALPHA_2_0: 1.29.0.2
-        bsd_44_lite: 1.1.1.1
+        bsd_44_lite: 1.1.1.1                    \fI4.4BSD-Lite\fP\/
         CSRG: 1.1.1
 keyword substitution: kv
 total revisions: 179;   selected revisions: 179
 description:
 .De
-\fIcvs\fP\| expects to find the name of its repository in the environment
-variable \f(CWCVSROOT\fP, and it won't work if you don't put it there.  The
-repository contains a number of directories, depending on what you track.  In
-our case, we're tracking the source tree and the Ports Collection, so:
+This example shows the same file we saw on page
+.Sref \*[hooboy] .
+This time we use the
+.Command rlog
+command, which is part of \fIRCS\fP\/, to look at the revision log.  Normally
+you'd use
+.Command "cvs log" ,
+but that only works in a checked out source tree.
+.P
+There are a number of ways to tell
+.Command cvs
+the name of its repository:  if you already have a
+.Directory CVS
+subdirectory, it will contain files
+.File Root
+and
+.File Repository .
+The name of the repository is in
+.File Root ,
+not in
+.File Repository .
+When you first check out files, you won't have this directory, so you specify
+it, either with the \f(CW-d\fP option to
+.Command cvs
+or by setting the \f(CWCVSROOT\fP environment variable.  As you can see in the
+example above, it's convenient to set the environment variable, since you can
+use it for other purposes as well.
+.P
+The repository contains a number of directories, usually one for each collection
+you track.  In our case, we're tracking the source tree and the Ports
+Collection, so:
 .Ls B
 .LI
-\fICVSROOT\fP\| contains files used by CVS.  It is not part of the source tree.
+\fICVSROOT\fP\/ contains files used by CVS.  It is not part of the source tree.
 .LI
-\fIports\fP\| contains the Ports Collection
+\fIports\fP\/ contains the Ports Collection.
 .LI
-\fIsrc\fP\| contains the system sources.
+\fIsrc\fP\/ contains the system sources.
 .Le
-The directories \fIports\fP\| and \fIsrc\fP\| correspond to the directories
-\fI/usr/ports\fP\| and \fI/usr/src\fP\| for a particular release.  To extract
-the \fIsrc\fP\| tree of the most up-to-date version of FreeBSD-CURRENT, do the
-following:
+The directories \fIports\fP\/ and \fIsrc\fP\/ correspond to the directories
+.Directory /usr/ports
+and
+.Directory /usr/src
+for a particular release.  To extract the \fIsrc\fP\/ tree of the most
+up-to-date version of FreeBSD-CURRENT, do the following:
 .Dx
 # \f(CBcd /usr\fP
 # \f(CBcvs co src 2>&1 | tee /var/tmp/co.log\fP
 .De
-To check out any other version, say, everything for release 2.2.2, you would
-enter
+.ne 5v
+To check out any other version, say, everything for Release 4.6, you would
+enter:
 .Dx
 # \f(CBcd /usr\fP
-# \f(CBcvs co -r RELENG_2_2_2_RELEASE world 2>&1 | tee /var/tmp/co.log\fP
+# \f(CBcvs co -r RELENG_4_6_RELEASE src 2>&1 | tee /var/tmp/co.log\fP
 .De
 If you need to check out an older version, for example if there are problems
-with the most recent version of -CURRENT, you could enter:
-.Dx
-# \f(CBcvs co  -D "10 December 1997" src/sys\fP
-.De
-This command checks out the kernel sources as of 10 December 1997.
-.X "cvs, command"
-.X "command, cvs"
-During checkout, \fIcvs\fP\| creates a subdirectory \fICVS\fP\| in each
-directory.  \fICVS\fP\| contains four files.  We'll look at typical values when
-checking out the version of the directory \fI/usr/src/usr.bin/du\fP for release
-2.2.2, from the repository at \fI/src/ncvs\fP\|:
+with the most recent version of \f(CW-CURRENT\fP, you could enter:
+.Dx 1
+# \f(CBcvs co  -D "10 December 2002" src/sys\fP
+.De
+This command checks out the kernel sources as of 10 December 2002.  During
+checkout,
+.Command cvs
+creates a subdirectory \fICVS\fP\/ in each directory.  \fICVS\fP\/ contains four
+files.  We'll look at typical values when checking out the version of the
+directory
+.Directory -n /usr/src/usr.bin/du
+for Release 4.6, from the repository at
+.Directory /home/ncvs \/:
 .Ls B
 .LI
-.X "CVS/Entries"
-\fIEntries\fP\| contains a list of the files being maintained in the parent
+.X "CVS, file, Entries"
+\fIEntries\fP\/ contains a list of the files being maintained in the parent
 directory, along with their current versions.  In our example, it would contain:
 .Dx
-/Makefile/1.1.1.1/Fri May 27 12:31:05 1994/TRELENG_2_2_2_RELEASE
-/du.1/1.6/Wed Oct 23 06:53:55 1996/TRELENG_2_2_2_RELEASE
-/du.c/1.6/Wed Oct 23 06:53:57 1996/TRELENG_2_2_2_RELEASE
-.De
-Note that \fIcvs\fP\| prepends a \f(CWT\fP to the version name.
-.LI
-.X "CVS/Repository"
-\fIRepository\fP\| contains the name of the directory in the repository which
-contains the repository for this directory.  This corresponds to
+/Makefile/1.4.2.1/Sun Jul  2 10:45:29 2000//TRELENG_4_6_0_RELEASE
+/du.1/1.15.2.7/Thu Aug 16 13:16:47 2001//TRELENG_4_6_0_RELEASE
+/du.c/1.17.2.3/Thu Jul 12 08:46:53 2001//TRELENG_4_6_0_RELEASE
+D
+.De
+Note that \fIcvs\fP\/ prepends a \f(CWT\fP to the version name.
+.LI
+.X "CVS, file, Repository"
+\fIRepository\fP\/ contains the name of the directory in the repository that
+corresponds to the current directory.  This corresponds to
 \fI$CVSROOT/directory\fP.  In our example, it would contain
-\f(CW/src/ncvs/src/usr.bin/du\fP.
+\f(CWsrc/usr.bin/du\fP.
 .LI
-.X "CVS/Root"
-\fIRoot\fP\| contains the name of the root of the repository.  In our example,
-it would contain \f(CW/src/ncvs/src/usr.bin/du\fP.
+.X "CVS, file, Root"
+\fIRoot\fP\/ contains the name of the root of the repository.  In our example,
+it would contain \f(CW/home/ncvs\fP.
 .LI
-.X "CVS/Tag"
-\fITag\fP\| contains the \fIversion tag\fP\| of the source tree.  This is the
+.X "CVS, file, Tag"
+\fITag\fP\/ contains the \fIversion tag\fP\/ of the source tree.  This is the
 RCS tag prefixed by a \f(CWT\fP.  In this case, it is
-\f(CWTRELENG_2_2_2_RELEASE\fP.
+\f(CWTRELENG_4_6_0_RELEASE\fP.
 .Le
-.X "cvs co, command"
-.X "command, cvs co"
-\fIcvs co\fP\| produces a lot of output\(emat least one line for each directory,
+\fIcvs co\fP\/ produces a lot of output\(emat least one line for each directory,
 and one line for each file it checks out.  Here's part of a typical output:
 .Dx
 U src/usr.sbin/mrouted/rsrr_var.h
@@ -689,680 +636,78 @@
 U src/usr.sbin/mrouted/mtrace/Makefile
 cvs checkout: Updating src/usr.sbin/mrouted/testrsrr
 U src/usr.sbin/mrouted/testrsrr/Makefile
-U src/usr.sbin/mrouted/testrsrr/testrsrr.c
 .De
-.X "cvs conflicts"
-.X "conflicts, cvs"
-The flag \f(CWU\fP at the beginning of the line stands \fIupdate\fP, but it can
-also mean that the file was checked out of the repository, as in this case.
-Other important flags are \f(CW?\fP, which means that \fIcvs\fP\| found the file
-in the directory, but it doesn't know it, \f(CWM\fP, which means that the file
-in your working directory has been modified since checkout, so \fIcvs\fP\|
-doesn't change it, and \f(CWC\fP, which implies a \fIconflict\fP\|: \fIcvs\fP\|
-found that the file was modified and was unable to merge the changes.
-.Highlight
+.X "CVS, conflict"
+.X "conflicts, CVS"
+.ne 5v
+The flag at the beginning of the line indicates what action
+.Command cvs
+took for the file.  The meanings are:
+.Ls B
+.LI
+\f(CWU\fP means that
+.Command cvs
+updated this file.  Either it didn't exist previously, or it was an older
+version.
+.LI
+You won't normally see \f(CWP\fP on a local update.  It implies that
+.Command cvs
+patched the file to update it.  Otherwise it has the same meaning as \f(CWU\fP.
+.LI
+\f(CW?\fP means that
+.Command cvs
+found the file in the directory, but it doesn't exist in the repository.
+.LI
+\f(CWM\fP means that
+.Command cvs
+found that the file in your working directory has been modified since checkout,
+but it either didn't need to change it, or it was able to apply the changes
+cleanly.
+.LI
+\f(CWC\fP found that the file in your working directory has been modified since
+checkout, and it needed to change it, but it was not able to apply the changes
+cleanly.  You will have to resolve the conflicts manually.
+.Le
 After checkout, check the log file for conflicts.  For each conflict, you must
-check the files manually and possibly recover the contents.
-.End-highlight
-See the man page \fIcvs(1)\fP\| for more details.
+check the files manually and possibly recover the contents.  See the man page
+\fIcvs(1)\fP\/ for more details.
 .H3 "Updating an existing tree"
 .X "updating an existing source tree"
 .X "source tree, updating an existing"
 Once you have checked out a tree, the ground rules change a little.  Next time
 you do a checkout, files may also need to be deleted.  Apart from that, there
 isn't much difference between checkout and updating.  To update the
-\fI/usr/src\fP\| directory after updating the repository, do:
+.Directory /usr/src
+directory after updating the repository, do:
 .Dx
 # \f(CBcd /usr/src\fP
-# \f(CBcvs update -P -d\fP
+# \f(CBcvs update -Pd\fP
 .De
-Note that this time we can start in \fI/usr/src\fP\|: since we now have the
-\fICVS/\fP\| subdirectories in place, \fIcvs\fP\| knows what to do without being
-given any more information.
+Note that this time we can start in
+.Directory /usr/src \/:
+we now have the \fICVS/\fP\/ subdirectories in place, so \fIcvs\fP\/ knows what
+to do without being given any more information.
 .H3 "Using a remote CVS tree"
 A CVS tree takes up a lot of space, and it's getting bigger all the time.  If
 you don't check out very often, you may find it easier to use \fIanonymous
 CVS\fP, where the tree is on a different system.  FreeBSD provides the server
-\fIanoncvs.FreeBSD.org\fP\| for this purpose.
+\fIanoncvs.FreeBSD.org\fP\/ for this purpose.
 .P
 For example, to check out the \f(CW-CURRENT\fP source tree, perform the
 following steps:
+.nr firstpage 2
 .Dx
-$ \f(CBcd /usr\fP				\fIgo to the parent directory\fP\|
-$ \f(CBCVSROOT=:pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs\fP \fIset the server path\fP\|
+$ \f(CBcd /usr\fP                                                   \fIgo to the parent directory\fP\/
+$ \f(CBCVSROOT=:pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs\fP   \fIset the server path\fP\/
 $ \f(CBcvs login\fP				\fIYou only need to do this once\f(CW
 Logging in to :pserver:anoncvs@anoncvs.freebsd.org:2401/home/ncvs
-CVS password:				\fIenter \f(CWanoncvs\fI; it doesn't echo\f(CW
+CVS password:                                               \fIenter \f(CBanoncvs\fI; it doesn't echo\f(CW
 $ \f(CBcvs co src\fP
 cvs server: Updating src
 U src/COPYRIGHT
 U src/Makefile
 U src/Makefile.inc1
-\&\fI(etc)\fP\|
-.De
-.sp -1v
-.H2 "Making a new world"
-.X "make world"
-The next step after making the source tree is to build all the software.  This
-is relatively simple for you, but depending on the speed of the machine, it may
-keep the computer busy for up to a day:
-.Dx
-# \f(CBcd /usr/src\fP
-# \f(CBmake world\fP
-.De
-This operation performs a number functions, which can be influenced by variables
-you pass to \fImake\fP.  Without any variables, \fImake world\fP\| performs the
-following steps:
-.Ls B
-.LI
-It removes the old build directories and creates new ones.  You can skip this
-step by setting the \f(CWNOCLEAN\fP variable.  Don't set \f(CWNOCLEAN\fP unless
-you know exactly why you are doing so, since it can cause inconsistencies which
-come back to bite you later.
-.LI
-It rebuilds and installs \fImake\fP, the C compiler and the libraries.
-.LI
-It builds the rest of the system, with the exception of the kernel.
-.LI
-It installs everything.  You can omit this stage by building the
-\fIbuildworld\fP\| target instead of \fIworld\fP.
-.Le
-.Df
-.TB "Targets for top-level \fIMakefile\fP\|"
-.TS
-box,center,tab(#) ;
-| lfCWp9 | lw65 | .
-\fRTarget#Purpose
-=
-buildworld#rebuild everything, including glue to help do upgrades.
-.sp .4v
-installworld#install everything built by \f(CWbuildworld\fP
-.sp .4v
-world#\f(CWperform buildworld\fP and \f(CWinstallworld\fP
-.sp .4v
-update#update your source tree
-.sp .4v
-most#build user commands, no libraries or include files
-.sp .4v
-installmost#install user commands, but not libraries or include files
-.sp .4v
-reinstall#T{
-If you have a build server, you can NFS mount the source and object directories
-and do a \f(CWmake reinstall\fP on the \fIclient\fP\| to install new binaries
-from the most recent build on the server.
-T}
-.TE
-.Tn build-targets
-.sp 1.5v
-.DE
-.Df
-.TB "Variables for \fImake world\fP\|"
-.TS
-box,center,tab(#) ;
-| lfCWp9 | lw64 | .
-\fRVariable#Function
-=
-ALLLANG#T{
-build documentation for all languages, where available.  See
-\fIshare/doc/Makefile\fP\| for more details.
-T}
-CLOBBER#remove \fI/usr/include\fP.
-.sp .4v
-MAKE_EBONES#build eBones (KerberosIV)
-.sp .4v
-NOCLEAN#T{
-Do not clean out the old build tree.  This can save on build time, but may
-introduce subtle problems.  You'll probably want to use this if your \fImake
-world\fP\| dies in mid-build.
-T}
-.sp .4v
-NOCLEANDIR#run \f(CWmake clean\fP instead of \f(CWmake cleandir\fP
-.sp .4v
-NOCRYPT#don't build  crypt versions
-.sp .4v
-NOGAMES#T{
-Don't rebuild the games.
-T}
-.sp .4v
-NOINFO#don't make or install info files
-.sp .4v
-NOLIBC_R#don't build \fIlibc_r\fP.
-.sp .4v
-NOLKM#don't build loadable kernel modules
-.sp .4v
-NOOBJDIR#don't run \f(CWmake obj\fP
-.sp .4v
-NOPROFILE#T{
-Don't build the profiling libraries.  If you're not doing any development
-involving profiling, this can save a considerable amount of time and space.  If
-you don't know what profiling libraries are, you don't want them.
-T}
-.sp .4v
-NOSECURE#T{
-Don't build the export-restricted modules.  If you haven't downloaded the
-source for these, then you won't want to try to build them.  This is a good
-option to use if you are not in the USA.
-T}
-.sp .4v
-NOSHARE#T{
-Don't rebuild \fI/usr/share\fP\|.  This can save some time, and if
-\fI/usr/share\fP\| (which contains manpages, data files and examples) hasn't
-changed much, it won't cause you any trouble.
-T}
-.TE
-.Tn build-variables
-.sp 1.5v
-.DE
-It does this by building a number of subtargets.  Occasionally, you might find
-it useful to build them individually.  Table \*[build-targets]
-.\" .pageref \*[build-targets-page] "on page \*[build-targets-page]" "\&" "on page \*[build-targets-page]"
-gives an overview of the more useful targets to the top-level \fIMakefile\fP,
-and table \*[build-variables]
-.\" .pageref \*[build-variables-page] "on page \*[build-variables-page]" "\&" "on page \*[build-variables-page]"
-gives an overview of the more common variables for \f(CWmake world\fP and
-\f(CWmake buildworld\fP.  Note that \f(CWmake world\fP doesn't rebuild the
-kernel.  This doesn't mean that it's optional: you need to keep some programs,
-for example \fIps\fP, in step with the kernel.  \f(CWmake world\fP builds
-\fIps\fP, but it doesn't build the kernel.
-.P
-The good news is: building the kernel for -CURRENT is just the same as it always
-is.  See \*[chbuild], for more details.  There is one possible problem that is
-specific to -CURRENT: if you try to build a kernel without first performing a
-\f(CWmake world\fP, you might find that the kernel fails to link with lots of
-undefined references.  One possible reason for this would be that the
-\fIconfig\fP\| program is out of synchronization with the kernel modules.
-Before you try anything else, rebuild \fIconfig\fP\|:
-.Dx
-# \f(CBcd /usr/src/usr.sbin/config\fP
-# \f(CBmake depend all install clean\fP
-.De
-.X "make clean"
-You need to \fImake clean\fP\| at the end since this method will store the
-object files in non-standard locations.
-.H2 "Putting it all together"
-There are a number of steps in updating a repository and building a new version
-of the operating system.  Make just a small mistake, and things won't work.  On
-the other hand, none of the steps are complicated.  This is obviously a job for
-a computer.
-.P
-.X "CVSup, command"
-.X "command, CVSup"
-The following script is designed to be run by \fIcron\fP.  It first updates the
-repository with \fICVSup\fP, then it updates the source tree with \fIcvs\fP, and
-finally it builds a new version of the system and the kernel.  If you schedule
-this script to start late at night on a fast machine, it should all be done by
-the following morning.
-.Dx
-echo ====== `date`: Getting CVSUP updates
-cvsup -g -L2 /src/cvsup/cvs-cvsupfile		\fIget the updates\fP\|
-cvsup -g -L2 /src/cvsup/secure-cvsupfile		\fIsecurity comes from a different site\fP\|
-echo ====== `date`: Updating /usr/src
-echo cd /usr/src
-cd /usr/src
-cvs update -P -d						\fIupdate the source tree\fP\|
-echo ====== `date`: Rebuilding TAGS
-cd /usr/src/sys
-rm -f TAGS								\fIrebuild TAGS file for Emacs\fP\|
-find . -follow -name "*.[csh]" | xargs etags -a
-echo ====== `date`: Rebuilding CURRENT
-echo cd /usr/src
-cd /usr/src
-make world								\fIrebuild everything\fP\|
-echo ====== `date`: Rebuilding FREEBIE kernel
-cd /usr/src/sys/compile
-mv FREEBIE/version .						\fIsave the version number\fP\|
-cd /usr/src/sys/i386/conf
-config -g FREEBIE						\fIreconfigure the kernel with debugging\fP\|
-echo cd /usr/src/sys/compile/FREEBIE
-cd /usr/src/sys/compile/FREEBIE
-cp ../version .							\fIrestore the version number\fP\|
-make -k								\fIand make everything we can\fP\|
-if [ $? -ne 0 ]; then					\fIfailed, give up\fP\|
-  echo ====== `date`: '***' Build failed
-  exit 1
-fi
-chflags noschg /kernel
-mv /kernel /kernel.yesterday				\fIsave the old kernel\fP\|
-rm -f kernel.gdb
-if [ -f /var/crash/kernel.gdb ]; then 
-  mv  /var/crash/kernel.gdb /var/crash/kernel.gdb.old  \fIsave any old /var/crash/kernel.gdb\fP\|
-fi
-cp -p kernel kernel.gdb					\fIrename kernel to debug version\fP\|
-ln -s kernel.gdb /var/crash/kernel.gdb		\fIand link to the current version\fP\|
-strip -d kernel							\fIstrip the kernel we're going to run\fP\|
-cp kernel /kernel						\fIand move it to the root directory\fP\|
-echo ====== `date`: Build completed
-if [ $? -eq 0 ]; then
-  echo ====== `date`: FREEBIE kernel build completed
-else
-  echo '******' `date`: FREEBIE kernel build failed
-fi
-.De
-You can, of course, use \fImake install\fP\| to install the kernel, but it will
-install the full debug kernel in the root file system.  Apart from the fact that
-it will fill up the file system\(emcurrently the debug kernel is about 10 MB in
-size, it will also fill up memory.
-.H2 "Living with FreeBSD-CURRENT"
-.X "FreeBSD-CURRENT, living with"
-.X "living with FreeBSD-CURRENT"
-Keeping up with FreeBSD-CURRENT requires work on your part.  You should be on
-the \f(CWFreeBSD-current\fP mailing list.  To join, send mail to
-\f(CWmajordomo@FreeBSD.org\fP with the single line text (not subject):
-.Dx
-subscribe FreeBSD-current
+\&\fI(etc)\fP\/
 .De
-If the mail ID that you want to add to the list is different from the ID you're
-sending from, put the ID at the end of the line.  This will require manual
-intervention to confirm that the user really wants to be on the list, so it can
-take longer.  It's always better to send the mail from the ID at which you want
-to receive the mail.
-.H3 "Build kernels with debug symbols"
-.Pn Debug-Kernel
-.X "kernel, debugging"
-FreeBSD-CURRENT is not as stable as the released versions.  To prepare yourself
-for possible problems, you should build kernels which include debug symbols.
-The resultant kernel is about 13 MB in size, but it will make debugging with
-\fIddb\fP\| (the kernel debugger) or \fIgdb\fP\| much easier.  Even if you don't
-intend to do this yourself, the information will be of great use to anybody you
-may call in to help.
-.P
-We looked at how to build a debug kernel on page \*[run-config].  If you're
-running -CURRENT, you might prefer to install the complete debug kernel.  Do
-this with:
-.Dx
-# \f(CBmake install.debug\fP
-.De
-instead of the usual target \f(CWinstall\fP.
-.H3 "Solving problems in FreeBSD-CURRENT"
-.X "solving problems in FreeBSD-CURRENT"
-.X "FreeBSD-CURRENT, solving problems in"
-You \fIwill\fP\| run into problems with FreeBSD-CURRENT.  When it happens,
-please first read the mailing list and possibly the mail archives (see
-\fIhttp://www.FreeBSD.ORG/search.html\fP\| for a search engine) and see if the
-problem has been reported.  If it hasn't, try to investigate the problem
-yourself.  Then send mail to \f(CWFreeBSD-current\fP describing the problem and
-what you have done to solve it.
-.P
-If you experience a panic, please don't just send a message to
-\f(CWFreeBSD-current\fP saying ``My kernel panics when I type \fIfoo\fP\|''.
-Remember that you're asking somebody to use their spare time to look at the
-problem.  Make it easy for them.  Go through this procedure:
-.Ls N
-.LI
-Update to the absolutely latest sources, unless emails have been warning against
-this.
-.LI
-If you have any local patches, back them out.
-.LI
-Recompile, from scratch, your kernel with \fIddb\fP\| and with complete symbols
-(see above).  If possible, don't strip your kernel before booting.
-.LI
-Report all details from the panic.  At an absolute minimum, give all information
-from \f(CWshow reg\fP and \f(CWtrace\fP.  
-.LI
-Try to dump the system.
-.Le
-If you don't do at least this, there isn't much chance that a mail message to
-\f(CWFreeBSD-current\fP will have much effect.
-.H2 "Problems with CVS"
-.X "problems with CVS"
-.X "CVS, problems with"
-Occasionally, you'll run into problems updating your source tree.  Here are some
-possibilities:
-.H3 "Can't find directory"
-Occasionally \fIcvs\fP\| will crash during an update with a message like:
-.Dx
-cvs update: Updating games/sail
-U games/sail/externs.h
-cvs update: Updating games/snake
-cvs update: Updating games/snake/snake
-U games/snake/snake/snake.c
-cvs update: Updating games/snake/snscore
-cvs update: Updating games/tetris
-cvs [update aborted]: cannot open directory /src/cvs/src/games/tetris: No such file or
- directory
-.De
-.sp -1v
-.Aside
-This particular incident occurred after the owner of the name \fITetris\fP\|
-required FreeBSD to remove the game then called \fItetris\fP\| from the sources.
-.End-aside
-The problem here is that the file \fI/usr/src/games/CVS/Entries\fP\| still
-contained a reference to the directory, so \fIcvs\fP\| failed.  One way to fix
-this problem is to manually edit the file \fICVS/Entries\fP, but it's easier to
-remove the \fICVS\fP\| directory and start again:
-.Dx
-# \f(CBcd /usr/src/games\fP
-# \f(CBrm -rf CVS\fP							\fIremove the CVS information\fP\|
-# \f(CBcd ..\fP								\fIgo to the parent directory\fP\|
-# \f(CBcvs co games 2>&1 | tee /var/tmp/co.log\fP\fP		\fIand check the games directory out again\fP\|
-.De
-..if XXX
-.H3 "CVS doesn't update files"
-Rename CVS dir, try co again
-
-===> usr.sbin/sendmail/src
-"Makefile", line 24: Need an operator
-"Makefile", line 26: Need an operator
-"Makefile", line 32: Need an operator
-make: fatal errors encountered -- cannot continue
-*** Error code 1
-
-Stop.
-*** Error code 1
-
-Stop.
-
-
-<<<<<<< Makefile
-CFLAGS+=-I${.CURDIR} ${DBMDEF} ${NIS} -DNAMED_BIND=1 #-DNETISO
-=======
-# If you want tcp wrapper support, uncomment the following two lines
-#TCPWRAPPERSBASEDIR=	/usr/local
-#TCPWRAPPERS=		-DTCPWRAPPERS -I${TCPWRAPPERSBASEDIR}/include
-
-CFLAGS+=-I${.CURDIR} ${DBMDEF} ${NIS} ${TCPWRAPPERS} #-DNETISO
->>>>>>> 1.13
-
-SRCS=	alias.c arpadate.c clock.c collect.c conf.c convtime.c daemon.c \
-	deliver.c domain.c envelope.c err.c headers.c macro.c main.c map.c \
-	mci.c mime.c parseaddr.c queue.c readcf.c recipient.c safefile.c \
-	savemail.c srvrsmtp.c stab.c stats.c sysexits.c trace.c udb.c \
-	usersmtp.c util.c version.c
-
-C Makefile
-
-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-Date: Fri, 3 Oct 1997 09:49:22 -0500
-From: Karl Denninger  <karl@Mcs.Net>
-To: Mike Smith <mike@smith.net.au>
-Cc: Invis <invis@visi.com>, freebsd-current@FreeBSD.ORG
-Subject: Re: How much work does running -current take?
-X-Mailer: Mutt 0.64
-
-On Fri, Oct 03, 1997 at 11:40:48PM +0930, Mike Smith wrote:
-> > 
-> > 1. If I install -current, will I have to do 'make worlds' or other 6 hour CPU
-> >        tasks often?
-> 
-> You won't have to.  You may want to.
-> 
-> > 2. Will my system more often than not be able to boot and run most of the time?
-> >    i.e. I have one computer, I don't mind constant reboots, even making my own
-> >    code patches if necessary, but if this is something it's almost necessary
-> >    to have two machines for, please tell me!
-> 
-> It can be helpful to have two systems, but things are generally better 
-> now than they were in terms of re-bootstrapping yourself.
-> 
-> >     3. Where can I get a list of new features available in 3.0-current ??
-> 
-> The CVS commitlogs are the most verbose resource.
-> 
-> mike
-
-There are times when -current is EXTREMELY unstable.
-
-My hints and tricks include:
-
-1)      If you have two machines, its a REALLY good idea to keep one of
-        them in usable condition at all times until you've completed testing
-        on new stuff.
-
-2)      Any time the kernel changes drastically enough that libkvm and
-        friends (ie: ps, etc) needs to be rebuilt you can get screwed.  Use
-        extra caution at those times.  Those are the times when its most
-        dangerous, because you might not be easily able to back out a bad
-        change.
-
-3)      Learn how to check out and/or update your local copy with the "-D"
-        switch to cvs (ie: cvs update -D "yesterday" .).  This can save your
-        bacon if you ARE rebuilding all the time and one day it breaks when
-        you knew it was ok yesterday.
-
-4)      If you are making local changes to the sources (we do here) be
-        extremely cautious in exactly how you go about things.  You must
-        learn how CVS actually does stuff so you don't accidentially lose
-        your local changes.  ALWAYS, ALWAYS keep a local context diff of
-        your changes against a known base version SOMEWHERE ELSE.
-
-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-Date: Mon, 6 Oct 1997 20:38:52 -0400 (EDT)
-From: jack <jack@diamond.xtalwind.net>
-To: Richard Wackerbarth <rkw@dataplex.net>
-cc: hackers@FreeBSD.ORG
-Subject: Re: Help finding CVSup 15.2
-
-On Mon, 6 Oct 1997, Richard Wackerbarth wrote:
-
-> At John's request, I upgraded to the latest CVSup.
-> (He's OOT. Otherwise I would have just asked him to help solve this)
-> 
-> Unfortunately, the package needs some "X" libraries. I don't have them on
-> my servers.
-> 
-> Can someone point me to a version of CVSup 15.2 that is linked without
-> using the graphical libraries?
-
-     * ftp://hub.freebsd.org/pub/CVSup/cvsup.nogui-bin-15.2.tar.gz
-       (client without GUI).
-
-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-
-From: Kenneth Merry <ken@plutotech.com>
-Subject: Re: Current 3.0 10-9-97i
-To: rbolin@netchannel.net (Ron Bolin)
-Date: Fri, 10 Oct 1997 10:03:32 -0600 (MDT)
-Cc: freebsd-current@FreeBSD.ORG
-X-Mailer: ELM [version 2.4ME+ PL28s (25)]
-
-Ron Bolin wrote...
-> In building the present current, the ps command gives the following
-> error:
-> 
-> rlb3:/home/rbolin>ps -a
-> ps: proc size mismatch (1312 total, 652 chunks)
-> 
-> I believe this is connected with a change in the proc file system as the
-> man pages shows several different
-> directories under /proc that I don't have. Where is the best place to
-> determine what to do when changes are made in
-> current like this - or is browsing the source the only place or am
-> I just in the middle of some in progress work?
-
-        The best way to find out when changes like this are made is to read
-the -current mailing list, and the cvs-all list.
-
-        Whenever you get errors like that from ps, or w (I'd bet that w
-will give you bogus results as well), the best thing to do is:
-
-rebuild and reinstall libkvm
-then, rebuild ps, w, and top
-
-        I just updated the kernel on one of my machines last night, and I
-got a similar error message.  Rebuilding things in that order fixed them
-for me.  (and that will almost always fix problems like that)
-
-(BTW, you might want to adjust your mailer so that it doesn't send both
-text and html versions of your mail...)
-
-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-
-Check the cvs update stuff for C conflicts
-
-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-
-
-From: Greg Lehey <grog@lemis.com>
-To: David Kelly <dkelly@nebula.tbe.com>
-Cc: FreeBSD Hackers <hackers@freebsd.org>
-Bcc:
-Subject: Re: How to get an older if_de.c?
-Reply-To:
-In-Reply-To: <199801202309.RAA10002@PeeCee.tbe.com>; from David Kelly on Tue, Jan 20, 1998 at 05:09:40PM -0600
-Organization:   LEMIS, PO Box 460, Echunga SA 5153, Australia
-Phone:          +61-8-8388-8286
-Fax:            +61-8-8388-8725
-Mobile:         +61-41-739-7062
-WWW-Home-Page:  http://www.lemis.com/~grog
-
-You sent this message to -hardware, which doesn't seem appropriate.
-I'm following up to -hackers.
-
-On Tue, Jan 20, 1998 at 05:09:40PM -0600, David Kelly wrote:
-> I'm guessing the solution to my de0 problem is an older version of
-> if_de.c ???
->
-> dmesg says:
-> de0 <Digital 21040 Ethernet> rev 35 int a irq 11 on pci0:14
-> de0: not configured; 21040 pass 2.0 required (0.0 found)
->
-> or maybe there is a way to hack my early December version
-> into compliance? In the mean time an old NE2000 clone has
-> been pressed into service.
->
-> I have the CVS directory tree, updated via CTM as of this
-> morning. If some one could get me started on how to use CVS
-> to trace the history of if_de.c and extract a selected version
-> then I'd be happy. Would also like to know how to protect that
-> copy against further upgrades on my machine.
-
-OK.
-
-1.  To get the revision history, use cvs log:
-
-> $ cvs log if_de.c
-> RCS file: /src/cvs/src/sys/pci/if_de.c,v
-> Working file: if_de.c
-> head: 1.77
-> branch:
-> locks: strict
-> access list:
-> symbolic names:
-
-These are mappings between names and RCS version numbers.  You won't
-see the names again in the list of changes, which list only the
-version numbers.  Refer back here to tranform the version number to a
-version name.
-
->         v971020: 1.1.1.5
->         RELENG_2_2_5_RELEASE: 1.54.2.9
->         v971017: 1.1.1.4
->         NETBSD: 1.1.1
->         v970703: 1.1.1.3
->         WOLLMAN_MBUF: 1.65.0.2
->         BP_WOLLMAN_MBUF: 1.65
->         v970513: 1.1.1.2
->         v970508: 1.1.1.1
->         MATT_THOMAS: 1.1.1
->         RELENG_2_2_2_RELEASE: 1.54.2.5
->         post_smp_merge: 1.64
->         pre_smp_merge: 1.64
->         RELENG_2_2_1_RELEASE: 1.54.2.3
->         RELENG_2_2_0_RELEASE: 1.54.2.3
->         RELENG_2_1_7_RELEASE: 1.29.2.8
->         RELENG_2_1_6_1_RELEASE: 1.29.2.7
->         RELENG_2_1_6_RELEASE: 1.29.2.7
->         RELENG_2_2: 1.54.0.2
->         RELENG_2_2_BP: 1.54
->         RELENG_2_1_5_RELEASE: 1.29.2.5
->         wollman_polling: 1.44.0.2
->         RELENG_2_1_0_RELEASE: 1.29.2.5
->         RELENG_2_1_0: 1.29.0.2
->         RELENG_2_1_0_BP: 1.29
->         RELENG_2_0_5_RELEASE: 1.28.2.1
->         RELENG_2_0_5: 1.28.0.2
->         RELENG_2_0_5_BP: 1.28
->         RELENG_2_0_5_ALPHA: 1.27
->         OLAH_TTCP: 1.7.0.2
->         RELEASE_2_0: 1.7
->         BETA_2_0: 1.6
->         ALPHA_2_0: 1.4
->         V941001: 1.1
-> keyword substitution: kv
-> total revisions: 102;   selected revisions: 102
-
-The following are the change strings for each version.
-
-> description:
-> ----------------------------
-> revision 1.77
-> date: 1998/01/08 23:42:24;  author: eivind;  state: Exp;  lines: +5 -2
-> Make INET a proper option.
->
-> This will not make any of object files that LINT create change; there
-> might be differences with INET disabled, but hardly anything compiled
-> before without INET anyway.  Now the 'obvious' things will give a
-> proper error if compiled without inet - ipx_ip, ipfw, tcp_debug.  The
-> only thing that _should_ work (but can't be made to compile reasonably
-> easily) is sppp :-(
->
-> This commit move struct arpcom from <netinet/if_ether.h> to
-> <net/if_arp.h>.
-> ----------------------------
-> revision 1.76
-> date: 1997/12/15 20:31:25;  author: eivind;  state: Exp;  lines: +3 -1
-> Throw options IPX, IPXIP and IPTUNNEL into opt_ipx.h.
->
-> The #ifdef IPXIP in netipx/ipx_if.h is OK (used from ipx_usrreq.c and
-> ifconfig.c only).
->
-> I also fixed a typo IPXTUNNEL -> IPTUNNEL (and #ifdef'ed out the code
-> inside, as it never could have compiled - doh.)
-
-2.  To check out a version, you can use either a date spec, a version
-    name, or a version number.  For example, you may determine that
-    you want the version before the SMP merge (label pre_smp_merge:
-    1.64).  Here's the checkin information (from cvs log):
-
-      revision 1.64
-      date: 1997/04/05 07:59:41;  author: phk;  state: Exp;  lines: +2 -2
-      Recognize ZNYX 314 cards that have a MAC address with the low bit set.
-
-   You can use one of the following methods to check out this version:
-
-   a.  By date:
-
-       cvs update -D "5 April 1997 07:59:41 UTC" if_de.c
-
-   Note that RCS (and thus cvs) keeps its dates in UTC, so it's best
-   to specify your dates in UTC.  You can specify them locally, but
-   you then need to convert the time correctly.  RCS looks for the
-   latest version which existed at the time you specified: if you
-   specify "5 April 1997 07:59 UTC", you will get an older version,
-   but if you specify "5 April 1997 08:00 UTC" you'll get the one you
-   want.
-
-   b.  By revision number:
-
-       cvs update -r1.64 if_de.c
-
-   c.  By revision tag:
-
-       cvs update -r pre_smp_merge if_de.c
-
-A word of caution: all these methods are "sticky".  Any further update
-will give you the same version until you tell cvs something else.  For
-example, when you're ready for the latest and greatest version again,
-you can write:
-
-       cvs update -A if_de.c
-
-cvs keeps information on the current version in the file CVS/Entries.
-To see which version you currently have, enter:
-
-$ grep if_de.c CVS/Entries
-/if_de.c/1.64/Wed Jan 21 05:48:58 1998//D97.04.05.08.00.00
-
-Let me know if you need any more information; I'll add this to the
-next edition of "The Complete FreeBSD".
-
-Greg
-
---------------------------------------------------
-
-To remove patched  files,
-
-grep "RCS file" diffs | sed 's:.*freebsd/:/usr/:; s:,v$::'|xargs rm
-
-..endif
+.bp
+\&
