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.. 
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
I was told on #svn that this is due to the mixed revisions stuff.  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
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
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
This will save a _lot_ of file-creation and removal afterwards.
Received on Sat May 7 17:57:38 2005
- application/pgp-signature attachment: stored