[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ideas to make svn update faster.

From: Branko ─îibej <brane_at_xbc.nu>
Date: 2005-05-08 20:04:05 CEST

Folker Schamel wrote:

> Some additional notes:
> Performance under windows really is a serious problem;
> it is much worse than under Linux due to the windows file system.
> My impression is that unix-only-users often are not aware of this.
> My personal experience is: what costs only seconds under Linux
> often costs a minute under windows (e.g. a svn status; but strongly
> depending on the current state of the file system cache,
> which is worse under windows).

Yes, sad but true... Windows filesystem performance sucks tremendously.
Of course, it doesn't help that we have to do more work on Windows, too
(like removing the read-only flag before deleting a file).

> And there's another fundamental difference between windows
> and linux: The Tortoise performance is really critical,
> because it is integrated into the windows explorer itself.
> I am not aware of something similar on Linux.
> A command line command hanging for some time is one thing.
> But the windows explorer itself hanging for several seconds is another.
> The performance of the tortoise shell extension probably is the most
> critical performance issue compared to all other svn clients.
> This is the reason why I really don't like suggestions for performance
> "optimizations" without being aware of Tortoise or not using windows
> at all. ;-) Linux is really cool, but it is a fact that far the biggest
> market share is windows. At the end it is one reason for the success
> of svn that svn has a really good windows support.

Ach, if only there were more Windows developers on the SVN team, too...

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 8 20:05:04 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.