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

Re: Perforce/Subversion Timing Statistics #2

From: Ben Collins <bcollins_at_debian.org>
Date: 2002-05-28 20:22:44 CEST

On Tue, May 28, 2002 at 12:50:16PM -0500, Ben Collins-Sussman wrote:
> I'm not sure why I'm replying to this, as it seems like
> flamebait... however Joshua has been very polite in his findings. :-)
> "Joshua Jensen" <jjensen@workspacewhiz.com> writes:
> > No, I don't believe my tests are missing the whole picture. I have
> > proven that:
> >
> > * Adding files to Perforce is significantly faster than Subversion.
> This seems true... Berkeley DB is probably the culprit here. I
> wouldn't be surprised to learn that BDB is slower than whatever
> proprietary DB perforce is using.

Perforce stores files in RCS layout, and the metadata in db format.

> > * Branching files is significantly faster than Subversion. This
> > operation will happen far less frequently, though, but still takes a
> > long, long time.

I didn't look closely at the test, but are you sure this is correct?
Perforce has a different way of branching than any other setup I have
seen. Requires two steps, one to create the branch (which is just a
description on the server) and the other is to sync/commit the branch.
That took a considerable amount of time for me using perforce (basically
a full checkout, then commit).

As BenS points out, server-side branching (the only kind I will ever do)
is a 2 second operation regardless of the size of the dataset being
branched. Subversion clearly wins in this case.

Debian     - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 28 20:30:50 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.