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

ideas to make svn update faster.

From: Thomas Zander <zander_at_kde.org>
Date: 2005-05-07 17:56:12 CEST

Hi;
I'm a kde developer and as such lived through the cvs-svn conversion of the
kde codebase. I even blogged a bit about that.. [1]

One of the things I notice is that svn update is not faster then cvs update,
which is contrary to expectations since there should be a global tree
revision, so it should be faster then the cvs which has a revision per
file.
I was told on #svn that this is due to the mixed revisions stuff. [2] Which
I fully understand. Looking at strace output I notice that svn could be a
lot faster (do less writes) if svn was to be more optimistic about version
numbers.

kdelibs has ~8800 files and 378 dirs. At any time maybe 10 files have a
different version then the rest (hell; let it be 10%). That means that
around 370 .svn/entries files have been written with the only change being
a new version number in the name="" entry that is equal to just about all
the other dirs in the project.
A simple optimalisation would be to remove the directory-version number (the
one in the xml entry-tag with 'name=""') when it has the same one as the
parent dir.
Its probably not goint to be as simple as that (since you update subdirs
seperately), but I'm pretty sure that a lot less xml's have to be written
if you follow the route that the normal state is a dir having the same
version as its parent. Only when that fails do you need to do extra work.
Being optimistic about version changes; I'd call that.

Now; there is probably going to be a lot of opinions on the above subject;
and I'd like to point out that svn really needs speed optimalisations; I
have seen a LOT of complaints about this issue in the KDE switchover.
Remember that if you find the above suggestion technically less-then-ideal.

The strace also showed me things like;
* the .svn/format file is opened 5 times for each directory. I would think
that with auto-upgrades only one (the root dir) should be enough. Saving
5*378 -1 open-files for me. :)

* .svn/lock files being created in every subdir is not needed if you check
parent dirs that also have a .svn (and maybe the same root).
So you create one in the dir you typed 'svn up' in and if someone types svn
up in a subdir it will change dir to parent and check for a lock file until
it either finds it (in this case it will, and abort) or it will leave the
checkout.
This will save a _lot_ of file-creation and removal afterwards.

1) http://www.kdedevelopers.org/node/view/1028
2) http://colabti.de/irclogger/irclogger_log/svn?date=2005-05-07,Sat#l1300

-- 
Thomas Zander

  • application/pgp-signature attachment: stored
Received on Sat May 7 17:57:38 2005

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