"Joshua Jensen" <jjensen@workspacewhiz.com> writes:
> > > * Retrieving new files from Perforce is significantly faster than
> > > Subversion.
> >
> > The svn client must 'walk' the entire working copy in order
> > to report its state to the server. Perforce doesn't need to do this.
>
> I can't imagine this is it. There isn't a working copy yet. All files
> being transferred are new. No directories have been created.
Oh sorry, I was describing how 'svn up' works.
For checkouts, we're building a whole lot of metadata in .svn, and
we're currently very inefficient about reading/writing our entries
files. My guess is that at least 50% of the time required for 'svn
co' is just lots of disk-diddling within .svn/ areas as the files
arrive. Perforce, as I understand it, is storing the metadata
server-side, so it has a big advantage there. (Of course, svn still
has tons of room for optimization here -- since CVS checkouts are
still much faster.)
> > Try creating a branch server-side:
> >
> > svn cp URL1 URL2
>
> I will try this later.
>
Actually, this feature accidentally broke about a week ago, so don't
try it ATM. It will be fixed when we switch to our new repository
code RSN! :-)
> > 'svn merge' is receiving diffs from the server, and applying
> > them to the working copy. The slowness you're seeing is in
> > the commit, as you say.
> >
> > Just as with updates, it takes 30 seconds for svn to commit,
> > because it must 'walk' over the entire working copy,
> > searching for changed files. Perforce doesn't need to do this.
>
> Could be, except other commits only took a few seconds, as I previously
> reported, on the same directory structure. Something must be different.
Huh? Not sure what data you're referring to here. Maybe you're
witnessing OS caching of files on second runs?
> Assuming everyone is going to have large amounts of disk space is like
> assuming all servers will have 2+ gigs of RAM. It isn't going to
> happen. Do you really want Subversion to be confined to a niche market
> or do you want everyone to use it? I'm far more likely to use a piece
> of software that makes efficient use of the resources it is given. Just
> my opinion...
Careful in your accusations -- svn may seem like its making
"inefficient use" of disk resources, but it's actually a very
deliberate *tradeoff* decision we've made. The tradeoff is that svn
makes significantly less use of network than CVS does -- 'svn status'
requires no network access, and neither does 'svn revert'. The client
also sends diffs to the server during commits. The tradeoff, of
course, is that your working copy is twice as big.
Similarly, using BDB or some giant SQL db on the server is indeed much
larger than a tree of RCS files, but the tradeoff is huge
flexibility. Once we have SQL going, you'll be able to query the
repository in ways undreamed of in CVS.
It all depends on your priorities.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:36:10 2002