Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Nov 1997 10:05:04 +1030
From:      Mike Smith <mike@smith.net.au>
To:        Nate Williams <nate@mt.sri.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: Version Resolution? 
Message-ID:  <199711202335.KAA00759@word.smith.net.au>
In-Reply-To: Your message of "Thu, 20 Nov 1997 16:21:17 PDT." <199711202321.QAA11798@mt.sri.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711202335.KAA00759>