-----Original Message-----
From: Greg Hudson [mailto:ghudson@MIT.EDU]
Sent: Mon 7/18/2005 5:34 PM
To: Ben Collins-Sussman
Cc: KRONSTORFER Horst; dev@subversion.tigris.org
Subject: Re: How are (atomic) commits implemented?
> On Mon, 2005-07-18 at 07:46 -0500, Ben Collins-Sussman wrote:
>> 2. N different users can be 'writing' to separate transactions at
>> once. The only time anyone ever has to wait is the microsecond where
>> somebody's transaction is "promoted" to become the new HEAD
>> revision; that action needs to be serialized. (In the case of BDB,
>> it's a single row insert. In the case of FSFS, it's an file move.)
> Ben makes it sound a little simpler than it is. If two people try to
> commit at the same time, they both build a transaction on the server;
> then, one of the commits is finalized, and the other one has to be
> "auto-merged" with the first one. The auto-merge algorithm knows how to
> merge together compatible directory operations, but will fail out if
> both commits make changes to the same file.
'auto-merge' would also include that the changes made by the 1st commit are
merged 'on the fly' into the local copy of the one who did the later commit?
did you mean 'auto-merge' fail for *conflicting* changes to the same file.
> Also, in FSFS the finalization of a commit is not just a file move; the
> transaction has to be converted from a form with easily-mutable
> directory entries to the more compact (but not easily modified) form
> used in revision files. This means FSFS has a larger serialization
> window than BDB, although it's still pretty quick (the slow steps of
> receiving the new data from the client and computing file deltas have
> already been accomplished before finalization begins).
Received on Wed Jul 20 03:42:56 2005