Date: Mon, 24 Nov 1997 15:23:06 -0700 From: Nate Williams <nate@mt.sri.com> To: Richard Wackerbarth <rkw@dataplex.net> Cc: Eivind Eklund <perhaps@yes.no>, brian@awfulhak.org, freebsd-stable@FreeBSD.ORG Subject: Re: Version Resolution? Message-ID: <199711242223.PAA24374@mt.sri.com> In-Reply-To: <l03110703b09f8a1710e6@[208.2.87.4]> References: <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
Richard Wackerbarth writes: > At 1:22 PM -0600 11/24/97, Eivind Eklund wrote: > >I'll oppose anything that break the repositories (ANY case where they > >break the repositories) > > or absolutely need manual intervention. I'm > >willing to accept growth (as long as it is low compared to the growth > >of the rest of the repository). > > > >Was that included in your sentiment? > > It all depends on how you define your terms. > > By "break the repositories", I will accept only the following > 1) Causes CVS to hang/abort, etc. 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. [ 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. ---- The same behavior could happen on *any* site that uses the new branch *before* the RCS-file generator blows it away, including on freefall. And, since the RCS-file generator must be hand-modified, the chance of someone doing it are somewhere between 0 and nil for people that actually create branches. Requiring someone to understand how RCS files are generated/built just to do branching is an unacceptable burden. If auto-recognition is implemented, the RCS-branch will never get blown away hence no 'branch' will get lost in the file which are ever used. 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 Julian has some as well, but they weren't in the file I looked at. And, I expect branches to start being used more often than in the past due to more commericial interests wanting to share their code with FreeBSD, as well as developers interested in using CVS to 'showcase' their new development, now that distribution is much more effecient with CVSup. In the past, the use of branches was *way* too expensive in terms of resources due to the use of SUP as the main distribution mechanism for many developers/users, but since SUP is no longer supported, the remaining distribution mechanisms allow for the greater use of branches. > 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, so you can't have *some* of the data available and not have all of it available. The only thing you *can* do is remove *some* of the very old Attic files in parts of the system which are not used at all, but that is a small percentage of the overall size of the system. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711242223.PAA24374>