Yup. I'm sure.
I can also tell, from the timing data, that the time is spent during the
lock and unlock phases, and it is proportional to either the number of
directories or the number of files in the subtree rooted at the file /
directory upon which the svn operation is performed. The time to perform the
actual operation is, as advertised, only proportional to the size of the
My data are valid.
They are not fully detailed, as I don't want to take the hours it would take
to generate a full data table. They should be enough for people to identify
the likely source of problem, the priority, and decide whether / how to fix
One thing which the data categorically show is that the delay is _not_ due
to virus scanners (for one thing, that process sits at 0% CPU for the entire
time that the svn client is locking). They also show that the delay is not
due to the client used.
Both Tortoise and the official command-line client exhibit the behavior.
Tortoise is a little slower to use, but only because it inserts extra steps
into the process for most operations (it filters the subtree to see what has
changed so that it can present the information in a GUI - information that
the command-line client doesn't present, so doesn't calculate).
I'm not a developer; I don't know what the problem is. However, I do know a
few things that it isn't.
Thank you, again, to the people who are trying to solve this. I really do
appreciate product. I think it would be significantly better with this
problem fixed, and I want to do what I can to help you fix it. I appreciate
those who are working with me to find a resolution.
From: Ph. Marek [mailto:email@example.com]
Subject: Re: Svn scaling issue
On Friday 14 January 2005 21:31, Arlo Belshee wrote:
> Can't really get 'em on a linux system. I may be able to get them on OS X.
> On Winders, command-line client gives the results indicated.
> Timings are unchanged by excluding the entire working dir from the virus
Are you sure about that? I know that some virus-scanners are awful to
configure properly - we've had to invest some time to get that right ...
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jan 17 23:07:03 2005