From owner-freebsd-stable Thu Nov 20 19:41:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA07385 for stable-outgoing; Thu, 20 Nov 1997 19:41:33 -0800 (PST) (envelope-from owner-freebsd-stable) Received: from word.smith.net.au (s204m97.whistle.com [207.76.204.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA07380 for ; Thu, 20 Nov 1997 19:41:29 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id KAA00759; Fri, 21 Nov 1997 10:05:05 +1030 (CST) Message-Id: <199711202335.KAA00759@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: freebsd-stable@freebsd.org Subject: Re: Version Resolution? In-reply-to: Your message of "Thu, 20 Nov 1997 16:21:17 PDT." <199711202321.QAA11798@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Nov 1997 10:05:04 +1030 From: Mike Smith 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. Er, I'd have thought it was pretty obvious that it *doesn't* increase without bounds. The number is a transaction identifier; it would ideally be inserted into the RCS files along with the other transaction details. It would be exported as a product of the checkin, not checked in itself. This would have the added (but perhaps dubious) advantage of making commits serialised. If there is a timestamp already associated with every commit, then this timestamp would be more than adequate, as long as it could be considered atomic. ie. no commits relating to a later timestamp could appear in the tree before all commits for an earlier timestamp were complete. This would involve locking some global object, effectively seralising write access to the repository. You wouldn't actually have to store anything in this file (thinking about it). Yes, you would have to hack CVS not immodestly in order to implement this; in particular regenerating the object as part of a checkout operation would involve tracking the most recent timestamp of any commit valid for the checked out file(s). Given that you may only be traversing a portion of the repository, it would have to be borne in mind that the token only applied to the segment checked out/updated. It is, however, the only practical way that I can see of producing a single token which uniquely identifies the state of the tree at a given point in time and can be used to regenerate that state. Do you want to talk about this more? I know you have CVS blood under your fingernails; it's definitely a value-add feature 8). mike