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

Re: SVN transactions

From: Gregory (Grisha) Trubetskoy <grisha_at_apache.org>
Date: 2006-06-16 02:06:08 CEST

On Wed, 14 Jun 2006, Ben Collins-Sussman wrote:

> Trying to understand subversion semantics by looking at DAV traffic is
> like trying to understand western philosophy by watching MTV!

LOL :-)

> You don't need to guess at this stuff through observation: just read
> the repository (filesystem) API in svn_fs.h.

The problem is that I cannot use fs, because the requirement is that it
works remotely, most likely via dav_svn, so I must use ra.

> It has long documentation explaining transactions and how they work.
> The RA API is just a shallow layer on top of that. The real 'theory' of
> the repository is in svn_fs.h.

I'll take a look. More comments below.

>> Or am I underestimating SVN here? Can I actually rollback a transaction?
>>
>
> A transaction starts life as a copy of the latest revision tree. You
> make changes to the transaction tree, then attempt to commit it. If
> newer changes have been committed in the meantime, the repository
> attempts to merge your changes with the new changes. This the dumbest
> sort of merge: if nobody else has changed the same files you're
> changing, then there's no conflict, and the commit succeeds. If
> someone else *has* changed the same file you're changing, a conflict
> is declared, and the commit fails. At that point, the transaction can
> be re-edited and resubmitted for commit again, or can just be aborted
> (deleted). It's your choice.
>
> The RA commit editor is just a thin layer over the svn_fs.h API. It
> happens to automatically abort a transaction which fails due to
> conflicts, but if you choose to use svn_fs.h directly, you'll have
> more control.

I don't know about "thin" - if you consider that it's a layer on top of
neon (in case of DAV)... "limited" is probably a more accurate
description.

I've just done some tests, and it appears like you say - if [using ra]:

   o transaction A creates a (new, previously non-existent) directory X
   o transaction B creates X
   o A is committed
   o B is commited

     ...the B commit fails, the entire transaction is aborted, and there
seems to be no way to get an explanation from ra as to what the problem
was - all you get is:

ERROR: ("MERGE request failed on '/blah/blah/trunk'", 160024)

... this is rather unfortunate, it'd be nice if there was some way to
reatract, or at least get details of the problem.

> (So the issue of 'rollback' doesn't come into play here. If a
> transaction *does* get successfully committed, a new global revision
> tree is created, and that tree is permanent and immutable. The only way
> to 'undo' a committed change is to submit a transaction which changes
> files back to the way they used to be.)

Yep, that's the way I understood it.

Now if transaction A attempts to create an already existing directory X,
then that operation alone fails, but the editor "lives on", which at least
is some good news... :)

Thanks for the detailed response,

Grisha

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 16 02:06:47 2006

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