You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Gustavo Niemeyer <ni...@conectiva.com> on 2002/09/03 19:16:45 UTC
Re: CVSROOT type functionality?
Hello Robert!
> True. This reflects what feels like an odd overload to me. It would
> seem more natural to me to have svn commands act on working directories
> (always), and reserve all direct repo actions for svnadmin (for that
> well deserved extra dose of respect). That seems more intuitive to me
> than having some commands have "direct commit" semantics. But that's
> probably not going to be considered at this point in the game.
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.
--
Gustavo Niemeyer
[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CVSROOT type functionality?
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
Quoting Robert W Anderson <rw...@alumni.princeton.edu>:
> Gustavo Niemeyer wrote:
>
> >Hello Robert!
> >
> >
> >
> >>True. This reflects what feels like an odd overload to me. It would
> >>seem more natural to me to have svn commands act on working directories
> >>(always), and reserve all direct repo actions for svnadmin (for that
> >>well deserved extra dose of respect). That seems more intuitive to me
> >>than having some commands have "direct commit" semantics. But that's
> >>probably not going to be considered at this point in the game.
> >>
> >>
> >
> >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.
> >
> >
> What you've said is not really an argument against my svnadmin idea, but...
>
> I think what you are saying is that a copy "in the repo" is cheaper than
> a working directory copy because of the (linked, I guess) repo
> representation as opposed to the (true copy) filesystem representation.
>
> But I still don't get it. I would expect the only reason to branch is
> if you are at some point interested in having a working directory of the
> branched files (otherwise, why bother). So you eventually have to pay
> for a "real" copy in either case. Either the copy is expensive and the
> commit is cheap, or the copy is cheap and the checkout is expensive.
> Right?
>
> What's the difference?
>
> Bob
>
Well, there are other things than just branches. The same thing applies tags,
which you may not want to have checked out.
Another scenario would be a dev lead or someone else creating a branch for a
different developer to checkout, or they may want to check it out on a
different machine. I.e. it is good to have the option to delay the cost of
the operation, even it is required at some point.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CVSROOT type functionality?
Posted by Ben Collins-Sussman <su...@collab.net>.
Robert W Anderson <rw...@alumni.princeton.edu> writes:
> But I still don't get it. I would expect the only reason to branch is
> if you are at some point interested in having a working directory of
> the branched files (otherwise, why bother).
As pilchie said, 'svn cp URL URL' can make a tag as well, just for
safekeeping. You may never actually get around to checking it out.
> So you eventually have to pay for a "real" copy in either case.
> Either the copy is expensive and the commit is cheap, or the copy is
> cheap and the checkout is expensive. Right?
Not always. Here's an example of cheap copy, cheap checkout:
$ svn cp http://foo.com/project/trunk \
http://foo.com/project/branches/branch1
$ cd trunk
$ svn switch http://foo.com/project/branches/branch1
That switch command will basically do nothing but rewrite your working
copy's entries files; there's no data to receive from the server.
But now you have a working copy of the branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CVSROOT type functionality?
Posted by Robert W Anderson <rw...@alumni.princeton.edu>.
Gustavo Niemeyer wrote:
>Hello Robert!
>
>
>
>>True. This reflects what feels like an odd overload to me. It would
>>seem more natural to me to have svn commands act on working directories
>>(always), and reserve all direct repo actions for svnadmin (for that
>>well deserved extra dose of respect). That seems more intuitive to me
>>than having some commands have "direct commit" semantics. But that's
>>probably not going to be considered at this point in the game.
>>
>>
>
>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.
>
>
What you've said is not really an argument against my svnadmin idea, but...
I think what you are saying is that a copy "in the repo" is cheaper than
a working directory copy because of the (linked, I guess) repo
representation as opposed to the (true copy) filesystem representation.
But I still don't get it. I would expect the only reason to branch is
if you are at some point interested in having a working directory of the
branched files (otherwise, why bother). So you eventually have to pay
for a "real" copy in either case. Either the copy is expensive and the
commit is cheap, or the copy is cheap and the checkout is expensive. Right?
What's the difference?
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Long-lived transactions
Posted by Branko Čibej <br...@xbc.nu>.
Peter Davis wrote:
>On Wednesday 04 September 2002 12:35, Branko Čibej wrote:
>
>
>>But on the other hand, these long-lived transactions you proposed behave
>>exactly like locks on HEAD should behave!
>>
>>
>
>Not quite, I think he was inventing a way to do a bunch of "svn {rm,mv,cp}
>URL" in a single commit. Well, I guess you're showing the same thing with
>locks, but I wasn't aware that changes to a locked URL directory (not wc)
>would all belong to the same transaction/commit. Was that part of the
>locking idea?
>
I think locks should behave like that, yes.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Long-lived transactions
Posted by Peter Davis <pe...@pdavis.cx>.
On Wednesday 04 September 2002 12:35, Branko Čibej wrote:
> But on the other hand, these long-lived transactions you proposed behave
> exactly like locks on HEAD should behave!
Not quite, I think he was inventing a way to do a bunch of "svn {rm,mv,cp}
URL" in a single commit. Well, I guess you're showing the same thing with
locks, but I wasn't aware that changes to a locked URL directory (not wc)
would all belong to the same transaction/commit. Was that part of the
locking idea?
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Long-lived transactions
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>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.
>
>
But on the other hand, these long-lived transactions you proposed behave
exactly like locks on HEAD should behave! With locks, your example:
> 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
>
would become:
cl=http://svn.collab.net/repos/svn/trunk/clients
svn lock $cl -m 'Reorganizing the clients directory'
svn mv $cl/cmdline $cl/cmdline.old
svn mv $cl/cmdline.new $cl/cmdline
svn ci $cl
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Long-lived transactions (was Re: CVSROOT type functionality?)
Posted by Nuutti Kotivuori <na...@iki.fi>.
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@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
Long-lived transactions (was Re: CVSROOT type functionality?)
Posted by Greg Hudson <gh...@MIT.EDU>.
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