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
Received on Wed Sep 4 02:36:43 2002