From owner-freebsd-stable Sun Nov 23 16:03:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA14098 for stable-outgoing; Sun, 23 Nov 1997 16:03:27 -0800 (PST) (envelope-from owner-freebsd-stable) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA14078 for ; Sun, 23 Nov 1997 16:03:20 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.5/8.8.5) with ESMTP id SAA19921; Sun, 23 Nov 1997 18:03:15 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199711232328.AAA17394@bitbox.follo.net> References: Nate Williams's message of Thu, 20 Nov 1997 16:21:17 -0700 <199711202218.PAA11561@mt.sri.com> <199711202300.JAA00612@word.smith.net.au> <199711202321.QAA11798@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 23 Nov 1997 18:03:36 -0600 To: Eivind Eklund From: Richard Wackerbarth Subject: Re: Version Resolution? Cc: freebsd-stable@FreeBSD.ORG Sender: owner-freebsd-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> > It has to be done by CVS; each commit increments a counter. This means >> > that simultaneous commits become impossible, as the object containing >> > the counter has to be locked as part of the commit. >> >> This file then increases w/out bounds, which is unacceptable. > >Why? > >Seriously; I don't consider expanding files a good thing, but I >actually can't see that this is a problem in this case. The CVS >repository is increasing 'without bounds' already; we have much more >data added each day than this. I don't see that this bloat is that >serious. (I don't like the solution, but I don't see it as a fatal >flaw - we can, if necessary, nuke the file w/history with regular >intervals). That is, in effect, what I do. The only problem is that Nate INSISTS that we must AUTOMATICALLY recognize new branches. He is somehow afraid that someone might mess up the RCS template if they were to do it manually. I don't accept his arguments. There are already plenty of ways that people already cause problems when they make a mistake. I feel that holding this code to a higher standard is unwarranted. He also rejects the claim that the changes occur only once or twice a year. However, I leave it to the reader to examine the branch point dates of 2.0, 2.1, and 2.2 and today's date. I refuse to spend the extra effort to automate this function when we have not even established that the overall methodology will be something that is actually retained. I argue that we should install the code as things are and, based on actual experience, see what changes are needed. Once the scheme is stable, the automation can be added as an enhancement. Richard Wackerbarth