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>
index | next in thread | previous in thread | raw e-mail
> > > 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. Natehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711210529.WAA13140>