Skip site navigation (1)Skip section navigation (2)
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>