Date: Thu, 20 Nov 1997 22:29:17 -0700 From: Nate Williams <nate@mt.sri.com> To: Mike Smith <mike@smith.net.au> Cc: Nate Williams <nate@mt.sri.com>, freebsd-stable@freebsd.org Subject: Re: Version Resolution? Message-ID: <199711210529.WAA13140@mt.sri.com> In-Reply-To: <199711202335.KAA00759@word.smith.net.au> References: <199711202321.QAA11798@mt.sri.com> <199711202335.KAA00759@word.smith.net.au>
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. How does that number get increased on a 'regular' basis so that the sources can be more uniquely ID'd? Somehow this ID must be propogated via *ALL* distribution means, which are currently: 1) CVSup of the CVS bits, and subsequent checkout 2) CVSup of the actual bits, which are dumped in /usr/src 3) CTM of the CVS bits, and subsequent checkout 4) CTM of the actual bits dumped into /usr/src 5) Remote CVS (less of an issue) 6) SUP (does this still exist anymore) 7) SNAPS on releng22.freebsd.org/current.freebsd.org 8) CD-ROMS (though less of an issue since they are fairly static. :) > 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. Where is this timestamp stored, so that if I build a kernel from sources that take a long time to propoate (3 days) and you build a kernel that you got from those sources the same day it the timestamp was generated that we end up with the same 'timestamp'. > 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). You'd have to know what the timestamp was, and this 'timestamp' would have to be updated in a common file, unless you wanted to parse *every* file in the /sys directory to determine the time-stamp, which is unacceptably obnoxious. > 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. If I understand you correctly, it's much too expensive to generate a continually increasing 'timestamp' just to build kernels, and it also blows away the effect of someone's local changes making the entire tree 'tainted', which is not necessarily the case. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711210529.WAA13140>