Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: 3.1.7-pre-1 for the workers
- X-seq: zsh-workers 10966
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Oliver Kiddle <opk@xxxxxxxxxxxxx>, Zsh hackers list <zsh-workers@xxxxxxxxxxxxxx>
- Subject: Re: 3.1.7-pre-1 for the workers
- Date: Thu, 27 Apr 2000 09:23:05 +0000
- In-reply-to: <390793BB.1CF0@xxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <E12kWmF-00020A-00.2000-04-26-19-43-12@xxxxxxxxxxxxxxxxxxxx> <390793BB.1CF0@xxxxxxxxxxxxx>
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.<odd-number-greater-than-2>".
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author