From owner-freebsd-arch Thu Jan 31 5:20:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id DE28237B400 for ; Thu, 31 Jan 2002 05:20:43 -0800 (PST) Received: from pool0005.cvx22-bradley.dialup.earthlink.net ([209.179.198.5] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WH8r-000694-00; Thu, 31 Jan 2002 05:20:41 -0800 Message-ID: <3C5944A4.4927F812@mindspring.com> Date: Thu, 31 Jan 2002 05:20:36 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number References: <79300.1012474898@axl.seasidesoftware.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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