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