[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: Ben Collins-Sussman <sussman_at_newton.collab.net>
Date: 2001-01-18 01:24:28 CET

Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:

> I definitely agree that it would be weird. It just seemed to me that
> that would be the way subversion works from the design doc. I guess my
> question was how does the server distinguish between a normal commit
> like this, and a branch. Based on the design doc it seems as if they are
> identical, unless the client takes care of distinguishing between the
> two. Am I missing something from the design doc?

Sorry... the design doc right now really doesn't explain the issue of
concurrency in the filesystem. Take a look at libsvn_fs/structure
document.

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.

That's the verbose description -- nothing at all to do with
branching. Remember that "branching" in the filesystem is simply the
creation of a new subdirectory which points to an existing subtree
elsewhere. It's part of the "cheap copy" model. When you first make
a copy of a subtree, it's a tag. If you commit in that subdir, you
have a branch.
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.