Quoting Robert W Anderson <firstname.lastname@example.org>:
> 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.
> What's the difference?
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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Sep 4 02:40:29 2002