Thomas Zander <firstname.lastname@example.org> writes:
> 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.
TortoiseSVN uses non-recursive status on directories, with your scheme
it might have to read multiple entries files, all the way back to the
root, rather than just the entries file for the directory in question.
That would be very unpopular with the TSVN crowd :)
> 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. :)
What version of Subversion are you using? When I try "svn update" it
only opens each format file once:
$ svn up -r5 . > /dev/null
$ strace -etrace=open svn up -r6 . 2>&1 | grep .svn/format
open(".svn/format", O_RDONLY) = 3
open("foo/.svn/format", O_RDONLY) = 3
open("foo/bar/.svn/format", O_RDONLY) = 3
I'm using Subversion trunk@HEAD but as far as I know Subversion 1.2
should be the same, I haven't tried earlier versions.
I've done work in the past to make Subversion working copy handling
faster, I haven't done so much recently because it's "fast enough" for
my relatively small working copies. There are a number of ideas for
One suggestion is that we get rid of the format file and just use the
entries file. Another idea is to cache the incomplete="true" write to
reduce the number of times the entries file is written. I think those
would be relatively simple ways to make update faster.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat May 7 20:52:05 2005