On Friday 26 January 2007 16:29 Gunter Ohrner wrote:
> Am Freitag, 26. Januar 2007 01:11 schrieb Gunter Ohrner:
> > After that it starts to scan all entries in the repository, not just
> > the entries below.
> Ok, this statement is correct, but that's not the part which slows fsvs
> down. Actually the update_tree finishes pretty quickly.
It should - as it knows its entries, it should be faster than find :-)
> The slow part happens on commit:
>
> Probably to query the repository for file changes, fsvs does
>
> ci__directory[commit.c:291] ./dir/file: action is 200, type is 1
>
> for each managed file, which takes 200 ms - 500 ms for a server roundtrip
> (or several roundtrips, I'm not sure).
>
> With 70000 managed files, that takes more than 5 hours, even if no single
> file has changed...
>
> So, in combination with the after-sync-repos-partial-ci-bug, this was the
> reason for my extremely long-running partial commit.
partial-commit-perf.patch didn't help?
> Did fsvs < 1.0.15 also do this on every commit? Wouldn't it be possible to
> query the server for file / attribute changes between the current local
> and svn HEAD revisions (as "svn diff --summarize" does) and just to ask
> the server for files reported as added, removed, modified or replaced?
We don't query the server for changes ... we just send our changes.
There's some bug that tells every directory that some children has changed ...
and so every directory gets opened on the server.
Do you have a log file in manageable size?
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
