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

SVN transactions

From: Gregory (Grisha) Trubetskoy <grisha_at_apache.org>
Date: 2006-06-14 18:03:27 CEST

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.

Or you could somehow keep track to "last good known" revision outside of
SVN, and if a transaction did not go completely OK, 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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 14 18:34:44 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.