On Tue, 2002-09-03 at 15:16, Gustavo Niemeyer wrote:
> It may seem strange if you're talking about simple commands in your
> working copy. But think about something like that: you have a repository
> where your trunk/ directory has about 50MB (a huge project) and you have
> dozens of developers working on 30 different branches of development,
> and 100 tags were already made. How do you add or remove a new branch?
> Are you going to checkout your whole repository ((1+30+100)*50 == 6.55GB)
> to add or remove a branch? The way it was implemented looks wonderful
> to me.
I think he was suggesting that you'd be able to use svnadmin for that
purpose. I don't see a compelling reason to go in that direction,
though.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 4 01:18:49 2002