From owner-freebsd-stable Fri Nov 21 13:27:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA14020 for stable-outgoing; Fri, 21 Nov 1997 13:27:06 -0800 (PST) (envelope-from owner-freebsd-stable) Received: from mail.san.rr.com (san.rr.com [204.210.0.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA13996 for ; Fri, 21 Nov 1997 13:26:48 -0800 (PST) (envelope-from Studded@dal.net) Received: from dt050n3f.san.rr.com (dt050n3f.san.rr.com [204.210.31.63]) by mail.san.rr.com (8.8.7/8.8.7) with SMTP id NAA07963 for ; Fri, 21 Nov 1997 13:26:35 -0800 (PST) Message-Id: <199711212126.NAA07963@mail.san.rr.com> From: "Studded" To: "FreeBSD Stable List" Date: Fri, 21 Nov 97 13:26:09 -0800 Reply-To: "Studded" Priority: Normal X-Mailer: PMMail 1.95a For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Version Resolution? Sender: owner-freebsd-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am certainly no expert on cvs, but I have an idea that I think is worth consideration. It solves several of the problems that have been discussed here. The basic idea is that CVS would maintain a database of the current state of the tree for a given tag. It would essentially be a list of the current revision number of each file that is part of that distribution. If someone checks out a file to do a commit, that file's state is updated in the database (or perhaps in a seperate file?). At the exact moment that someone does a commit, the current state of the database is marked. I would suggest using the last 8 digits of unix/ctime as the stamp. That gives you a time period of 16wks 3days 17hrs 46mins 40secs before the thing recycles. This is only 2 more digits than the date-based method we're using now, and you can always add an 8 to the front to get the exact time if you're curious. Of course, you could use all 9 digits if you want, I'm just trying to keep things short and sweet. :) The things I would want to know about before implementing something like this are how often are commits made to -Stable, and how often is more than one file open. If there aren't very many commits in a given day, this system may be overkill. A cron job that runs say, twice as often per day as the average number of commits which modifies newvers.sh with the date plus a number may be all you need. Something like 971121.1, etc. I think that the database idea has value in any case, even if it's more than we need for -Stable. You could make a cvs inquiry as to the exact state of the tree for any time period. Of course, all this comes with the unfortunate caveat that I can't code a line of this. I am interested in seeing it happen though, so I thought I'd make the suggestion in case someone who can code it is interested. :) Hope this helps, Doug *** Proud operator, designer and maintainer of the world's largest *** Internet Relay Chat server. 4,168 clients and still growing. :-) *** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD) *** Part of the DALnet IRC network ***