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

Re: Complexity of svn update?

From: Wayne <wayne_at_zk.com>
Date: 2007-10-31 22:47:28 CET

I believe that this would depend on the file system. I am pretty sure
that Windows has serious performance issues with a large number of files
in a single directory. Other file systems may have similar issues.

Miller, Eric wrote:
>> For example, suppose I have a repository with 100.000 files. Will it
>> take less time if all files are in the root directory (so the
>> repository does not have any subdirectories) than if I have lots of
>> directories and subdirectories where the files are scattered? If the
>> time to process each .svn directory is constant, processing one large
>> repository with everything in the root will take the same time as
>> processing an empty repository, which is much less time than the large
>> repository with the files scattered in lots of directories.
>>
>
> So you are really just wondering about the overhead of updating a
> hierarchical directory structure vs a flat one?
>
> Someone may correct me if I'm wrong, but reading/writing each
> .svn/entries file and creating/removing locks throughout the hierarchy
> would create additional disk thrash. AFAIK the optimal setup would be a
> flat structure.
>
> Should be easy enough to verify though - just create 2 repositories, one
> with 100k files in a directory and one with 100k directories with 1 file
> each and compare update times.
>
> Eric
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 31 22:46:32 2007

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.