From owner-freebsd-stable Thu Nov 20 16:40:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA25037 for stable-outgoing; Thu, 20 Nov 1997 16:40:42 -0800 (PST) (envelope-from owner-freebsd-stable) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA25027 for ; Thu, 20 Nov 1997 16:40:39 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id RAA22166; Thu, 20 Nov 1997 17:40:22 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id RAA12221; Thu, 20 Nov 1997 17:40:18 -0700 Date: Thu, 20 Nov 1997 17:40:18 -0700 Message-Id: <199711210040.RAA12221@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: chad@dcfinc.com Cc: nate@mt.sri.com (Nate Williams), rkw@dataplex.net, brian@awfulhak.org, andrsn@andrsn.stanford.edu, freebsd-stable@freebsd.org Subject: Re: Version Resolution? In-Reply-To: <199711210035.RAA04407@freebie.dcfinc.com> References: <199711210029.RAA12133@mt.sri.com> <199711210035.RAA04407@freebie.dcfinc.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> It would have to be a custom hack to CVS, letting it generate newvers.sh > >> on the fly at each commit. Then "simple timestamps" =would= work. > > > > That's what Richard's changes were doing. They also dealt with the > > issue of the files growing w/out bounds, and multiple branches, but they > > *didn't* deal with new branches appearing, which was the only sticking > > point I had with his solution. > > But there are (can be) seperate copies of newvers.sh in each branch? > Seems it would be an administrative procedure to touch it correctly as > part of creating a new branch. How often does that happen? Couple of > times a year? More than that, but as I stated before, file corruption even *once* isn't acceptable. The number of problems that will occur when a branch occurs (and everyone and his dog decides to finally download things) means that the # of questions due to bogus files is now bigger than the number of questions solved by implementing the solution. All it takes is some time to fix the 'added' branch problems, but Richard is too busy whining to go find a solution. ;( Nate