On 6/14/06, Gregory (Grisha) Trubetskoy <grisha@apache.org> wrote:
>
> On Wed, 14 Jun 2006, Greg Hudson wrote:
>
> > On 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.
> 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.
(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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 15 05:06:34 2006