[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Question about concurrent commits

From: Kevin Pilch-Bisson <kevin_at_pilch-bisson.net>
Date: 2001-01-18 01:28:57 CET

On Wed, Jan 17, 2001 at 06:24:28PM -0600, Ben Collins-Sussman wrote:
> Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> Think of the filesystem like this: you have an array of "revisions",
> each revision pointing to a complete filesystem tree. These are
> immutable. Then you also have an array of "transactions"; these are
> filesystem trees as well, and contain pointers to existing nodes, but
> whereever there are changes, the node is a new "cloned" node. These
> transactions are temporary things; when a transaction is finished, the
> filesystem attempts to merge the transaction-tree into the newest
> revision-tree. If successful, a new revision tree is created. If
> there's a conflict, the whole transaction aborts and all of the cloned
> nodes are deleted. It never happened.
> So... now pretend you have two processes working on separate
> filesystem transactions. These two transactions both modify the same
> file. So yes, this file's node is now cloned *twice* in two different
> temporary trees.
> If process A successfully merges its transaction tree first, then
> process B's transaction will fail. Why? Because the filesystem's
> "merge" system is very intolerant: if you attempt to merge a cloned
> node into a node that is out-of-date, it bails. In this particular
> case, process A committed a new version of the node first, so process
> B's entire set of changes is going to be rejected when it tries to
> modify the same node.
Okay, that makes sense, thanks for the clear explanation.

Kevin Pilch-Bisson

  • application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:19 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.