On Tue, Oct 28, 2008 at 11:49 AM, Harvey, Edward
<Edward.Harvey_at_patni.com> wrote:
> Put simply, as far as performance is concerned, Perforce has a strategy that beats the pants off either svn or git. Because perforce doesn't need to walk the tree.
I think this is one of those situations where most open-source users
(and developers on this project) simply haven't dealt with trees so
large that tree-walks become a serious hindrance to daily
productivity. Very few opensource projects are that large. But in
the corporate world (where both perforce and subversion are intensely
used) these huge working copies just aren't that unusual. At Google,
our main source tree is gi-normous... we would be *dead* if perforce
had to walk the tree to tell me which files I had changed. Heck,
even the Chrome Browser source that Google recently released (in a
public svn repository) is an unbelievably huge checkout. Same with
the 6 millions lines of Android code we released in git.
So while it's not the norm in opensource, I do think that an
(eventual) implementation of 'svn edit' methodology would make a huge
impact on the corporate world... perhaps some of Collabnet's clients
have made comments about this?
Whatever the case, the rewrite of libsvn_wc is what gstein is working
on now, and is highest priority. This whole 'svn edit' thing is just
a pie-in-the-sky thing that we'd like to add (as a strictly *optional*
mode) long after libsvn_wc2 has stabilized. No need to get excited
about it for now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-28 18:01:50 CET