Date: Tue, 25 Nov 1997 08:49:36 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: Nate Williams <nate@mt.sri.com> Cc: Eivind Eklund <perhaps@yes.no>, brian@awfulhak.org, freebsd-stable@FreeBSD.ORG Subject: Re: Version Resolution? Message-ID: <l03110707b0a090dacca7@[208.2.87.4]> In-Reply-To: <199711242223.PAA24374@mt.sri.com> References: <l03110703b09f8a1710e6@[208.2.87.4]> <l03110700b09e72675ae9@[208.2.87.4]> <199711240216.CAA28304@awfulhak.demon.co.uk> <199711240504.WAA22051@mt.sri.com> <199711241922.UAA21949@bitbox.follo.net> <l03110703b09f8a1710e6@[208.2.87.4]>
next in thread | previous in thread | raw e-mail | index | archive | help
At 4:23 PM -0600 11/24/97, Nate Williams wrote:
>Not recognizing new branches will cause CVS to abort when the file is
>modified out from underneath causing that revision/branch to disappear.
>
>RCS-HEAD == V1.10
>
>Steps:
>1) CVS branch on head occurs, causing the creation of branch V1.10.0.2,
> and revision V1.10.2.1.
The V1.10.2.1 never gets created unless some additional actions are taken.
But, in any case, it doesn't matter.
>[ Remote site operations ]
>----
>1) Remote update of CVS bits
>2) CVS update -RNEW_BRANCH src
> RCS-FILE is checked out, V1.10.2.1
>----
>
>3) Said file is re-created, causing the removal of both the new branch
> and new revision created in the branch tag, since new branches are
> not auto-recognizecd.
>
>[ Remote site operations ]
>----
>1) Remote update of CVS bits
>2) CVS update -RNEW_BRANCH src
>CVS loses it's mind, since neither the branch tag nor any revision even
>close to V1.10.2.1 exists in the repository.
>----
It really gets blown away ....
shrimp: {161} cvs update NATE
cvs update: Updating NATE
cvs update: NATE/RCS-FILE is no longer in the repository
shrimp: {162}
Hardly fatal, IMHO.
>Finally, just because branches haven't been used alot historically
>doesn't mean they won't be used in the future. In FreeBSD in the last
>year, I can count a number of branches that were created.
>
>RELENG_2_2
>SCSI
>WOLLMAN_MBUF
And since they only apply to a part of the tree, I don't think that a single
timestamp mechanism, even if it were done by the brut force update using CVS,
will do a reasonable job of tracking everything. Neither do I consider it
appropriate to attempt to track these odd tags. However, these kinds of
considerations are EXACTLY why I consider it premature to bother to automate
the new branch recognition. If it is decided that we really need to track
multiple tags which are not total trees, the whole mechanism may need to be
redesigned. If that is the case, the auto-recognition code would never get
used.
>> As for the rate of growth, I feel that we already have a significant
>> problem. I think that we need some alternate storage scheme that
>> allows MOST of the historical information to be taken off-line.
>
>CVS doesn't work that way. It's pretty much an all/nothing deal ...
I agree that that is the way the present methodology works. However, I
claim that we should look to alternatives. That does not mean that we need
to abandon CVS (although even that should not be ruled out offhand without
a valid cost/benefit analysis).
Perhaps we could simply start a new tree periodically. Those who NEED the old
stuff could refer to the archived version (on a CD?).
Don't take the above "solution" as one that I am advocating. I am simply
suggesting that it is appropriate to DISCUSS alternative methodology.
Particularly with the various tree reorganizations, there is IMHO too much
useless material that does not need to continue to be propogated everywhere
ALL the time.
Richard Wackerbarth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03110707b0a090dacca7>