Just to reconfirm my understanding of how transactions work, could someone
please comment on the following assertions:
When I create an editor via re, this starts a transaction (e.g. in DAV it
will cause a MKACTIVITY request).
When I close the editor, the transaction is commited. The result is
supplied to me via a callback in which I can examine what succeeded and
what didn't.
There is no such thing as a failed transaction as far as conflicts go -
transaction commit may not complete only for lower level reason, e.g. IP
connection lost.
There is no such thing as a transaction rollback (e.g. like in databases).
You could try to create a delta to the previous revision and attempt to
apply it to the youngest to simulate a "rollback", but that could cause
subsequent conflicts.
you could somehow keep track to "last good known" revision outside of
SVN, and if a transaction did not go completely K, perform subsequent
work with the "last good known" revision, not the youngest? Hmm but I
guess that might not work either, because the delta between "last good"
rev and your changes are not applicable to the youngest rev.
So perhaps the best way of keeping "transactional consistency" (or
whatever) is via creative us of copies rather than relying on revision
numbers.
Just to put this in context - I am trying to figure out a way to use SVN
as storage of verioned content in a scenario where it is driven by an
application, and human-driven conflict resolution (like when dealing with
source code) is not an option.
Thanks!
Grisha
To unsubscribe, e-mail: dev-unsubscribe (AT) subversion (DOT) tigris.org
For additional commands, e-mail: dev-help (AT) subversion (DOT) tigris.org

Wed, 2006-06-14 at 12:03 -0400, Gregory (Grisha) Trubetskoy wrote:
There is no such thing as a failed transaction as far as conflicts go -
transaction commit may not complete only for lower level reason, e.g. IP
connection lost.

As best I understand this, you are incorrect. Transactions can fail due
to conflicts.

you could somehow keep track to "last good known" revision outside of
SVN, and if a transaction did not go completely K, perform subsequent
work with the "last good known" revision, not the youngest? Hmm but I
guess that might not work either, because the delta between "last good"
rev and your changes are not applicable to the youngest rev.

Correct; all commits are against the head.

To unsubscribe, e-mail: dev-unsubscribe (AT) subversion (DOT) tigris.org
For additional commands, e-mail: dev-help (AT) subversion (DOT) tigris.org

Wed, 14 Jun 2006, Greg Hudson wrote:

Wed, 2006-06-14 at 12:03 -0400, Gregory (Grisha) Trubetskoy wrote:
>There is no such thing as a failed transaction as far as conflicts go -
>transaction commit may not complete only for lower level reason, e.g. IP
>connection lost.
>
As best I understand this, you are incorrect. Transactions can fail due
to conflicts.

Could you elaborate on this? My observation is based on looking at the
WebDAV conversation - when a transation is commited, a multi-response is
sent back listing in XML which file succeed and which didn't. But it goes
through either way, i.e. there is no option that says "abort if there is
conflict" in the API either.

am I underestimating SVN here? Can I actually rollback a transaction?

Grisha

To unsubscribe, e-mail: dev-unsubscribe (AT) subversion (DOT) tigris.org
For additional commands, e-mail: dev-help (AT) subversion (DOT) tigris.org

6/14/06, Gregory (Grisha) Trubetskoy <grisha (AT) apache (DOT) orgwrote:

Wed, 14 Jun 2006, Greg Hudson wrote:

Wed, 2006-06-14 at 12:03 -0400, Gregory (Grisha) Trubetskoy wrote:
>There is no such thing as a failed transaction as far as conflicts go -
>transaction commit may not complete only for lower level reason, e.g. IP
>connection lost.
>
As best I understand this, you are incorrect. Transactions can fail due
to conflicts.

Could you elaborate on this? My observation is based on looking at the
WebDAV conversation - when a transation is commited, a multi-response is
sent back listing in XML which file succeed and which didn't. But it goes
through either way, i.e. there is no option that says "abort if there is
conflict" in the API either.

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

You don't need to guess at this stuff through observation: just read
the repository (filesystem) API in svn_fs.h. 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.

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.

(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.)

To unsubscribe, e-mail: dev-unsubscribe (AT) subversion (DOT) tigris.org
For additional commands, e-mail: dev-help (AT) subversion (DOT) tigris.org

Thu, 15 Jun 2006 07:51:27 +0530, Ben Collins-Sussman
<sussman (AT) red-bean (DOT) comwrote:

[snip]

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.

IIUC, conflicts are much more fine grained conflicts arise not simply
because the same file is changed, but more specifically because the lines
that have been changed are conflicting

Pl. feel free to correct me if am wrong.

Regards,
Madan.

To unsubscribe, e-mail: dev-unsubscribe (AT) subversion (DOT) tigris.org
For additional commands, e-mail: dev-help (AT) subversion (DOT) tigris.org

Madan U Sreenivasan writes:
Thu, 15 Jun 2006 07:51:27 +0530, Ben Collins-Sussman
<sussman (AT) red-bean (DOT) comwrote:

[snip]
>
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.

IIUC, conflicts are much more fine grained conflicts arise not simply
because the same file is changed, but more specifically because the lines
that have been changed are conflicting

You're confusing conflicts on the client side (in the working copy) with
conflicts on the server side. What sussman was talking about was the latter.
Merging file contents is not done when committing a transaction.

Regards,
//Peter

To unsubscribe, e-mail: dev-unsubscribe (AT) subversion (DOT) tigris.org
For additional commands, e-mail: dev-help (AT) subversion (DOT) tigris.org

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!

LL :-)

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.

>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:

ERRR: ("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 (AT) subversion (DOT) tigris.org
For additional commands, e-mail: dev-help (AT) subversion (DOT) tigris.org

6/15/06, Gregory (Grisha) Trubetskoy <grisha (AT) apache (DOT) orgwrote:

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.

You are correct, sir. The RA layer is not, in fact, a port of the
repository API. It's just a limited set of network commands, only
those things that a subversion client might want to do. In the case
of commits, the client only wants to drive an editor and discover that
the commit succeeded or failed. It's nowhere near the level of
control you'd have if you were using svn_fs.h directly.

If you had time/energy, I think it *might* be possible to map all of
svn_fs.h to DAV/DeltaV methods, but it would be tricky. If you have
specific set of things you want to accomplish, we can probably help
you design a set of specific http requests to carry them out.

To unsubscribe, e-mail: dev-unsubscribe (AT) subversion (DOT) tigris.org
For additional commands, e-mail: dev-help (AT) subversion (DOT) tigris.org

Thu, 15 Jun 2006, Ben Collins-Sussman wrote:

6/15/06, Gregory (Grisha) Trubetskoy <grisha (AT) apache (DOT) orgwrote:

If you had time/energy, I think it *might* be possible to map all of
svn_fs.h to DAV/DeltaV methods, but it would be tricky. If you have
specific set of things you want to accomplish, we can probably help
you design a set of specific http requests to carry them out.

I am not going to make any promises - while I feel I am capable of not
only defining the requirements, but even actually submitting some patches
to help moving this forward, more likely than not for the current thing
I'm working on I'll be "going to war with the army we've got" (or whatever
that quote is) for the next couple of months, and _then_ look at the
possibility of improving SVN. Hopefully I'll be able to help.

Grisha

To unsubscribe, e-mail: dev-unsubscribe (AT) subversion (DOT) tigris.org
For additional commands, e-mail: dev-help (AT) subversion (DOT) tigris.org