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

CVS/Subversion/Perforce Timing Statistics (Take 3)

From: Joshua Jensen <jjensen_at_workspacewhiz.com>
Date: 2002-05-30 08:41:22 CEST

This just gets weirder and weirder...

First, my versions of everything:

CVS (Build 57d)
Subversion (Build 2038)
Perforce 2002.1

All repositories were LOCAL, although some tests accessed them via
'localhost'. Anything herein referred to as network means localhost.

Machine = AMD Athlon 1.4ghz with 512 megs DDR RAM, oodles of hard drive

So others can duplicate my tests, I used the following source code
archive: http://www.magic-software.com/ZipFiles/MSWindows1p3Free.zip

It was duped twice onto my G: drive, which is a separate hard drive from
the repository. The unzipped archive was duped once and named as


There are 1,264 files in 116 directories, comprising 8,574,128 bytes.

Instructions are below.

I MUST be doing something wrong, because the Perforce timings are not
very good.

Subversion Import (Network) : 12:26 (that's 12 MINUTES, 26 seconds)
Subversion Import (Local) : 3:20
Subversion Checkout (Network): 20:27 (this one is weird... see below)
Subversion Checkout (Local) : 8:03 (same here)
Subversion Update (Network) : 0:04 (sigh... a good number!)
Subversion Update (Local) : 0:04

CVS Import (Network) : 0:57
CVS Import (Local) : 0:18
CVS Checkout (Network) : 0:50
CVS Checkout (Local) : 0:31
CVS Update (Network) : 0:14
CVS Update (Local) : 0:06

Perforce Import (Network) : 0:41
Perforce Checkout (Network) : 0:20
Perforce Update (Network) : INSTANT

Creation of the repositories
[E:\]svnadmin create e:\svn

Apache was set up according to the provided Subversion instructions.
The latest build was used.


The repository was created with CVSNT's service, although it probably
equated to:
cvs -d e:\cvs\test init
A password was created with:
set cvsroot=:ntserver:MyComputerName:/TEST
cvs passwd -a "Joshua Jensen"
set cvsroot=:pserver:Joshua Jensen@MyComputerName:/TEST
A repository was set up according to this page:
The section called "Procedural example for creating a second Perforce NT
service" was used.
The repository resides at e:\pf
Importing into a fresh repository
Dirs has to exist in E:\svntest\Dirs for this to work.
Network [E:\svntest]svn import http://localhost/svn Dirs -m "Test"
Local   [E:\svntest]svn import file:///svn Dirs -m "Test"
Dirs/ has to exist in E:\cvstest\Dirs for this to work.
Network [E:\cvstest]cvs import -m "test" Dirs vendor release
Local   [E:\cvstest]cvs -d e:\cvs import -m "test" Dirs vendor release
Dirs has to exist in E:\pftest\Dirs for this to work.
Network [E:\pftest]dir /b /s /a-d | p4 -x - add
Checking out from a CLEAN directory
Network [E:\svntest]svn co http://localhost/svn Dirs
Local   [E:\svntest]svn co file:///svn Dirs
Oddly enough, Subversion 2038 actually checks Dirs out TWICE and does
NOT properly populate the .svn directory with the client side clones of
the local files.  Any ideas?
Network [E:\svntest]cvs co Dirs
Local   [E:\svntest]cvs -d e:\cvs\test co Dirs
Network [E:\pftest]p4 sync Dirs/...
        [E:\pftest]p4 edit Dirs/...
The additional 'p4 edit' simulates Subversion's and CVS's checkout,
although most Perforce users wouldn't do this.
Updating from the above retrieved directory
Network [E:\svntest\svn]svn update
Local   [E:\svntest\svn]svn update
Network [E:\cvstest\Dirs]cvs update
Local   [E:\cvstest\Dirs]cvs -d e:\cvs\test update
Network [E:\pftest]p4 sync Dirs/...
(And possibly a p4 resolve, but there are no changes at this point)
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:27 2002

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