From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15033 invoked from network); 27 Apr 2000 09:24:30 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 27 Apr 2000 09:24:30 -0000 Received: (qmail 28134 invoked by alias); 27 Apr 2000 09:24:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10966 Received: (qmail 28116 invoked from network); 27 Apr 2000 09:24:21 -0000 From: "Bart Schaefer" Message-Id: <1000427092306.ZM21039@candle.brasslantern.com> Date: Thu, 27 Apr 2000 09:23:05 +0000 In-Reply-To: <390793BB.1CF0@u.genie.co.uk> Comments: In reply to Oliver Kiddle "Re: 3.1.7-pre-1 for the workers" (Apr 26, 9:11pm) References: <390793BB.1CF0@u.genie.co.uk> X-Mailer: Z-Mail (5.0.0 30July97) To: Oliver Kiddle , Zsh hackers list Subject: Re: 3.1.7-pre-1 for the workers MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Apr 26, 9:11pm, Oliver Kiddle wrote: } Subject: Re: 3.1.7-pre-1 for the workers } } This reminds me: a number of the files in CVS seem to have a version } number which is something like 1.1.1.1. The CVS info page says something } about this having some special significance but I couldn't work out what } exactly. Does anyone know? When 4.0 is released, it might be a good idea } to advance all the files to be version 4.1 anyway, especially if the } 1.1.1 versions would cause problems if we created a branch later. No, no, no, no, no. Version numbers in CVS are effectively magical. They're used by CVS internally to determine branching properties and miscellaneous other details related to the functioning of the system. They no longer even have any meaningful relationship to RCS revision numbers, from which they originated. Forcing CVS to use particular numbers for a revision in the repository isn't the worst thing you can do to it, but it's not very far from. Please believe what I'm telling you. I recently spent most of a day fighting with CVS at one of Zanshin's consulting customer sites because exactly this sort of thing had been done to their repository at one time in the past. The Right Way to do versioning in CVS is with symbolic tags. With the sole exception of "cvs import -b ..." you should treat the numbering system as a black box; and the rule for "cvs import -b" is "don't use this under normal circumstances, but if you must, then always use a number of the form 1.1.". Without going into any great detail ... Revision 1.1.1 is what's called the "vendor branch." We have one because we started from a copy of Tanaka's repository, and he imported zsh as if it were source from a third-party vendor (which it was at the time he set his repository up). File revisions on the vendor branch will always have four numbers (three dots), beginning with 1.1.1. So a file with revision 1.1.1.1 is the first real revision on the vendor branch, which means only that it's a file that has not changed since Tanaka started his repository. It will not "cause problems" with any CVS operation we might want to do. Revisions with only two numbers (one dot) are "on the trunk." Revisions from the vendor branch (or even other branches, if the file was originally "cvs add"ed in a sandbox that was checked out on a branch) can be "on the trunk," too, because CVS doesn't actually assign a number to a revision until it has a non-empty delta with the revision that preceded it. The trunk is where mainline development normally takes place. When we make a stable release (3.1.7 might count, but maybe we should wait for 4.0.whatever-PWS-decides) we should probably create a branch that is explicitly for patches to the 4.0 series, while continuing the next (4.1?) development version on the trunk. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com