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

Re: Checkout really slow in Windows with lots of files in one directory

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Thu, 27 Jan 2011 07:51:19 -0500

On Wed, Jan 26, 2011 at 9:28 AM, Neil Bird <neil_at_jibbyjobby.co.uk> wrote:
>
>  We have a graphics-oriented code-base that's auto-generated and has >5000
> source files in one directory.  While I can check this out OK on Linux,
> we're seeing an unusable slow-down on Windows XP (NTFS), both using Tortoise
> directly, and as a test on Linux with the Windows drive mapped over CIFS.

Are you *normally* out to a CIFS shared location, or to local NTFS
disk? CIFS is very "chatty", and can often take 10 times as long to do
a checkout of a 1 Gig software working copy (in my personal
experience, 30 minutes instead of 3 for local disk).

Checkout to local disk, then copying it over to CIFS is grotesquely
faster. Maintaining a nightly updaed, checked out working copy for
copying to local working copies is also very effective to avoid this
slow down: the working copy can then be updated, far, far more
effectively.

>  The checkout starts sensibly enough, but then gets steadily slower and
> slower and slower, to the point were we're not sure it'd actually ever end.
>
>  I know that there's a negative speed difference on NTFS, and that 1.7's
> WC-NG might make this better, but this is getting near-logarithmically
> slower.
>
>  Is that to be expected, or at least known about?
>
>
>  (we're going to jigger the files around into sep. directories to get the
> individual counts down;  I expect that to help in this instance).
>
> --
> [neil_at_fnx ~]# rm -f .signature
> [neil_at_fnx ~]# ls -l .signature
> ls: .signature: No such file or directory
> [neil_at_fnx ~]# exit
>
Received on 2011-01-27 13:51:59 CET

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

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