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

Re: Long-lived transactions (was Re: CVSROOT type functionality?)

From: Nuutti Kotivuori <naked_at_iki.fi>
Date: 2002-09-04 22:51:55 CEST

Greg Hudson wrote:
> As a side note, people have complained in the past that you have two
> choices for directory operations:
> * Do your directory operations in a working dir, with all the
> * working
> dir overhead for big copies, and then commit it all at once, or
> * Do your directory operations on the repository one at a time,
> sacrificing atomicity.
> For the most common operations like creating a branch, the second
> choice is great. But for complicated tree reorgs, the user is in a
> bit of a bind.
> Long-lived transactions would solve this problem. People have
> talked about this as a possible post-1.0 feature on and off. As an
> example of how they could work, commands which can commit (ci, mv,
> cp, rm) could take a --transaction argument which causes them to
> commit in a named transaction rather than on the main path. New
> command would allow the user to create, list, commit, or destroy
> named transactions. So you might be able to do:
> repos=http://svn.collab.net/repos/svn
> cl=$repos/trunk/clients
> svn mktrans $repos reorg
> svn mv -t reorg $cl/cmdline $cl/cmdline.old
> svn mv -t reorg $cl/cmdline.new $cl/cmdline
> svn citrans $repos reorg
> The downside of long-lived transactions is that they feel a lot like
> branches, and having two ways of doing the same thing is poor. (We
> would start to get calls to be able to stick working directories to
> named transactions, to be able to merge into a transaction, stuff
> like that.) But it would mean being able to manipulate a repository
> without either creating a new revision or being chained to the
> performance characteristics of a working directory.

OK, sounds fine - but um, aren't we mixing two things here?
Implementation and interface?

This particular problem is simple - how can the user do multiple
operations in a single commit _without_ a working copy. That's it.

On the interface side, this sprouts a couple choices on how to do
this. The first choice would be just a simple shell:

| naked@oro:~$ svn shell
| $ cd http://svn.collab.net/repos/svn/trunk/clients
| $ mv cmdline cmdline.old
| $ mv cmdline.new cmdline
| $ commit

And before you scream bloody murder, substitute 'svn shell' with
'svnshell.py' or your favourite alternative.

The second choice is to have a way to save state between invocations
of the normal svn command. For example, a simple queuefile:

| naked_at_oro:~$ repos=http://svn.collab.net/repos/svn/trunk/clients
| naked@oro:~$ svn --queue /tmp/queue mv $repos/cmdline $repos/cmdline.old
| naked@oro:~$ svn --queue /tmp/queue mv $repos/cmdline.new $repos/cmdline
| naked@oro:~$ svn --queue /tmp/queue commit

Now - this all has _nothing_ to do with how the thing is actually
implemented. You can use long lived transactions, you can use locks on
HEAD, you can use clientside files or whatnot.

I think we should keep these things separate, so we can decide both on
the best interface and the best implementation.

Thank you for the airtime,
-- Naked

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 4 22:59:33 2002

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.