[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVSROOT type functionality?

From: Robert W Anderson <rwa_at_alumni.princeton.edu>
Date: 2002-09-04 02:36:22 CEST

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?


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.