Date: Wed, 2 Aug 2000 01:29:29 -0400 (Eastern Daylight Time) From: Chris BeHanna <behanna@zbzoom.net> To: FreeBSD-Stable <stable@freebsd.org> Subject: RE: Upgrade info request (fwd) Message-ID: <Pine.WNT.4.21.0008020123410.234-100000@armani.yourfit.com>
next in thread | raw e-mail | index | archive | help
I wrote the following in response to an off-list question from a
new FreeBSD-er who wanted to know how to track STABLE. I thought it
might be of more general use, so I'm forwarding it here. Apologies to
those of you who already know this stuff.
I wouldn't be the slightest bit heartbroken if someone stole from
it and compiled it into more formal documentation. :-)
Q: What is CVSup and how does it work? How do I run it?
Background
----------
First of all "CVS" is a source code control system that allows
files to be stored in versions. What it does is store a base
revision, and then it stores the changes that are needed to alter the
file to the next revision (and the next, and the next, and so on to
the most recent, or "head" revision). CVS can operate both on local
files and on files shared over a network.
Like any decent source code control system, CVS allows certain
revisions to be given symbolic names, or "tags". An entire source
tree can be given the same tag, and whatever the head revision of each
file was at the instant the tag was laid down is given the same tag.
Thus, the tagged revisions make up a "snapshot" of the source tree at
the instant the tree was tagged.
Also, like any decent source code control system, CVS allows
developers to branch off from the main line of development to develop
different versions of a product more or less independently. Changes
on the mainline and on the branches can be merged back and forth as
needed (e.g., when someone fixes something critical on the 5.0 branch,
they back-propagate the fix to the branches for previous versions).
The current active branches are 4.0-STABLE (identified by the CVS tag
RELENG_4) and 5.0-CURRENT (the mainline).
In FreeBSD-land, snapshots form the releases (3.4-RELEASE,
3.5-RELEASE, and so on). To make a release, a given branch is given a
tag, and the tagged branch becomes the release. For example, to make
4.0-RELEASE, the 4.0-STABLE branch was tagged with the label
"RELENG_4_0_0_RELEASE". To make 4.1-RELEASE, the 4.0-STABLE branch
was tagged branch with the label "RELENG_4_1_1_RELEASE". At that
instant, 4.0-STABLE became 4.1-STABLE, with 4.1-RELEASE being the
point of transition.
To recap, a tag is a symbolic name for a version of a file, and
several files can share the same tag, forming a snapshot in time of
those files' revisions. Files can be active on branches, as well, so
that changes in one branch don't break things in the other(s) (e.g.,
experimental stuff in 5.0-CURRENT doesn't break 4.0-STABLE because
they're on separate branches).
Here's a picture with a few representative events:
---X--------------X----------------------------> HEAD (5.0-CURRENT)
\ \
\ ---X-------------------X---> RELENG_4 (4.1-STABLE)
^ \ ^ ^ ^
| \--------X-+----+----------------X RELENG_3 (3.5-RELEASE)
| ^ | | ^ |
| | | | | |
| | | | | Snapshot that
Version 3.x | | Snapshot that | became
branch created | | became | 4.1-RELEASE. At
| | 4.0-RELEASE | this moment, 4.0-STABLE
| | | became 4.1-STABLE.
| | |
| | Snapshot
| Version 4.x that became
| branch created 3.5-RELEASE.
| This was the
Snapshot terminal release
that became for the 3.x branch,
3.4-RELEASE which is now retired.
Notice that development continues after a release. A release is
supposed to represent a very stable point during development, during
which extra care was taken to make sure that the operating system
didn't have any experimental code in it, and that as much stuff as
possible was working.
The ongoing development in the STABLE branch represents bug fixes
and well-tested enhancements and additions to the operating system.
The ongoing development in the CURRENT branch represents bleeding edge
development of new stuff that doesn't always work.
Don't worry if this is confusing at first. It takes a little
while to get used to the notion of a source code control system and
the idea of different branches of development, and it takes a couple
of hours of RTFM to master CVS. Fortunately, you don't have to master
it to use CVSup; it's sufficient just to understand the concepts.
CVS is implemented in the "cvs" command suite. Full documentation
(and a FAQ) is located at http://www.loria.fr/~molli/cvs-index.html .
CVSup
-----
"CVSup" is a protocol that FreeBSD uses for batch distribution of
changed files. The files are organized into packages. Whereas CVS
can update individual files, CVSup can only update collections of
files. Within each package, CVSup only updates the files that are
out-of-date.
CVSup's activity is controlled by two configuration files: a
"supfile" that tells CVSup what packages to update (and to what
revision tags to update them), and a "refuse" file to tell CVSup not
to update certain files within packages.
The CVSup protocol is implemented in the command "cvsup".
I hope that's been a helpful introduction. For more details, you
really need to refer to the handbook, in particular, Section 18:
http://www.freebsd.org/handbook/cutting-edge.html . The specific
instructions to get you started (including a template supfile) are
there. Be sure to read the comments in the supfile!
--
Chris BeHanna
Software Engineer (at yourfit.com)
behanna@zbzoom.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.WNT.4.21.0008020123410.234-100000>