From owner-freebsd-stable Tue Aug 1 22:29:42 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mail.yourfit.com (28.wxfr1.xdsl.nauticom.net [209.195.150.61]) by hub.freebsd.org (Postfix) with ESMTP id 8782E37BFE5 for ; Tue, 1 Aug 2000 22:29:31 -0700 (PDT) (envelope-from behanna@zbzoom.net) Received: from armani.yourfit.com (armani.yourfit.com [192.168.1.120]) by mail.yourfit.com (8.9.3/8.9.3) with ESMTP id BAA17457 for ; Wed, 2 Aug 2000 01:29:29 -0400 Date: Wed, 2 Aug 2000 01:29:29 -0400 (Eastern Daylight Time) From: Chris BeHanna Reply-To: behanna@zbzoom.net To: FreeBSD-Stable Subject: RE: Upgrade info request (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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