Hi! Sorry to bother you again... ;)
While testing the partial commit fix (and commits in general) I noticed an extreme performance degradation. At least it seems to be a degration, unfortunately I changed my configuration to webdav-powered svn on a faster server, so I could not make a direct comparison with fsvs-1.0.14. So far I failed to make adirect comparison with fsvs-1.0.4, however, I cannot remember to have seen such a bad performance ever before - although my previous SVN server was much, much slower than the current one. What happened? When comitting a directory with only two small added files (2 odt documents), fsvs performed the commit correctly, but it literally took *hours* to do so. Most of the time, nearly nothing seemed to happen, my laptop was idle, the server was mostly idle and only 1 - 2 kbyte/sec of data trickled through my ADSL link. Attaching to the process with strace revealed that fsvs was (at least) iterating over all directories currently managed, querying the server for each. It also iterated over directories which where a) unrelated to any local change and b) unrelated to the directory I specified for the partial commit. The strace log was full of: 23:08:18.496 ops__build_path[est_ops.c:531] 0xb6b3cd28 found in cache index 0; lru 0 23:08:18.496 hlp___do_convert[helper.c:128] before iconv from=misc/prog/customcdrom/ccdrom 23:08:18.496 hlp___do_convert[helper.c:135] after iconv to=misc/prog/customcdrom/ccdrom ret=0 23:08:18.496 ci__directory[commit.c:291] ./misc/prog/customcdrom/ccdrom: action is 200, type is 1 23:08:18.648 ci__directory[commit.c:384] baton for mod ccdrom 0x811f748 (parent 0x811d740) 23:08:18.648 ci__directory[commit.c:388] doing changes 23:08:18.648 ci__directory[commit.c:269] commit_dir with baton 0x811f748 and similar. fsvs did not seem to prune any path excluded by my partial commit filter. However, even for a full commit this performance would not be acceptable, ie. currently fsvs' usage for it's ultimate goal - managing whole software installations - is rather limited. :-( Why does fsvs touch all directories during a commit, even if nothing has changed locally? Is this some kind of "bug", or is it required by svn's architecture if you want to handle commits correctly? Client was a Core Duo 2 notebook, the server was a Athlon64 3800+, both where connected via an 4 MBit/sec ADSL link with 40 ms latency. Both systems are running Debian Linux i386 with subversion 1.4. The repository contains parts of my home directory and its current revision consists of 12455 directories and 70067 files at the moment. Greetings, Gunter -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The students were staring at her in the manner of those who have heard of the species 'female' but have never expected to get this close to one. -- (Terry Pratchett, Soul Music) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + PGP-verschlüsselte Mails bevorzugt! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
pgpKv2NHenCNF.pgp
Description: PGP signature
