Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Nov 1997 08:30:44 -0700
From:      Nate Williams <nate@mt.sri.com>
To:        Richard Wackerbarth <rkw@dataplex.net>
Cc:        Nate Williams <nate@mt.sri.com>, Eivind Eklund <perhaps@yes.no>, brian@awfulhak.org, freebsd-stable@FreeBSD.ORG
Subject:   Re: Version Resolution?
Message-ID:  <199711251530.IAA27130@mt.sri.com>
In-Reply-To: <l03110707b0a090dacca7@[208.2.87.4]>
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> <199711242223.PAA24374@mt.sri.com> <l03110707b0a090dacca7@[208.2.87.4]>

next in thread | previous in thread | raw e-mail | index | archive | help
> >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.

No, it gets created because when a branch for the entire tree is
created, then *every* file in the tree gets touched.

> >[ 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.

You didn't do it on a BRANCH.  Do it on a branch.  Also, there is
another possibility of something happening that even worse if branches
aren't auto recognized.

0) File is modified for new branch
1) CVS tree is gotten by remote user
2) Remote user checks out tree using branch
3) File is blown away by RCS-generator
4) File is re-generated againy by RCS-generator
...

5) New branch is desired to have timestamp, so someone edits the
   RCS-generator file and since the file is blown away, author doesn't
   know where the branch *was* originally, so he creates a 'new' branch
   where the BRANCH tag starts with.
6) Remote user syncs up his tree
7) CVS update -RBRANCH -  Again CVS loses it's mind since the branch was
   originally at V1.10.0.1, and now it's at V1.12.0.4. 
8) User/CVS is confused, causing developer headache because of Richard's
   laziness and whining.

> >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.

RCS file corruption is *exactly* the reason why you should track these
odd tags.  Whether *you* feel it's appropriate or not is not the issue,
the issue is whether or not you're willing to come up with a solution
that doesn't break the tree.  "But, I only break the tree for tags I
don't care about, and since I don't care about them the tree can break,
so don't generate tags that I don't care about."  IMHO that's total
*crap*.

> Perhaps we could simply start a new tree periodically. Those who NEED
> the old stuff could refer to the archived version (on a CD?).

You obviously don't understand the role of CVS/SCM solutions, do you?  I
often (every 2-3 mos.) go look back through very old versions looking
for hints to new fixes.  Starting over would be absolutely *silly*,
since the disk savings are insignificant compared to the keeping of the
history.  Heck, if we *could* do it, it would have been nice to have
kept the FreeBSD 1.X tree around publically, but that's not possible for
legal reasons, but because of it we lost many fixes.  Some have
subsequently been brought over, but some are probably still in the tree
that have been missed unfortunately. :(

> 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.

They are propogated *once*, and never again.  Throwing out all the
history because there is 5% wastage in the tree is *way* too much
overkill, and shows a lack of understanding about software development.


Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711251530.IAA27130>