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