Date: Thu, 31 Jan 2002 05:20:36 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number Message-ID: <3C5944A4.4927F812@mindspring.com> References: <79300.1012474898@axl.seasidesoftware.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Sheldon Hearn wrote: > I'd like to propose the addition of a global src tree serial number that > uniquely identifies an imaginary snapshot of the src tree. [ ... ] I see several issues; you may already have ways to address them. If I have serial number X, and two commits are started A,B, and the commits complete as either A,B or B,A, is the serial number X+1, X+2 or some other number? The easiest way to handle this would probably be to use a datestamp, in seconds; this would also allow checkout of a specific snapshot. If higher granularity were required, you could add a seperately incrementing value as a nonce. What is the interaction with the serial number and CVSup or explicit checkouts? Is the serial number updates at the start of a checkin, or at the end? Is it possible for the serial number to not match the code atomically? Is the increment on a per file, or a per checking basis? (I could perhaps see per file working better, since there are per file writer locks to prevent simultaneous commits). I don't really see how you could make atomicity guarantees that would keep this serial number from getting off-by-1 in one direction or the other, or off-by-N, in the case of a CVSup in the middle of a large commit (since repository replication is also non-atomic, at present). I definitely agree that it would be useful to be able to have a "magic number" that could get everyone on the same page with regard to a problem. For the "uname -a" idea, you would be better served by using a structure field. There is already version information (such as build date) in the "uname -a" that has to be retrieved by sysctl and string operations performed on it to provide minimal useful information. It would be a shame to compound that by adding more information to an unstructured field. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C5944A4.4927F812>