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:
> 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,
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Sep 4 22:59:33 2002