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

Re: Slow SVN Updates (though they shouldn't be).

From: Talden <talden_at_gmail.com>
Date: Sat, 9 Feb 2008 01:48:58 +1300

> It's pretty big, using find and wc, I've calculated it out:
>
> -- number of files
> ...
> 72216
>
> -- number of directories
> ...
> 37773
>
> I realize this is also counting all the files and subdirectories in .svn,
> so these numbers should be halved (roughly).

Actually since each 'real' folder may have all of this structure:

  .svn/
    prop-base/
    props/
    text-base
    tmp/
      prop-base/
      props/
      text-base/

And each .svn folder has two files, text-base has 1 file for every
file in the parent and prop-base will have a props file for each file
with properties....

realFolder ~= 37773 / 9 ~= 4200
realFiles ~= (72216 - (4200 * 2)) / 2 ~= 32000

I assume the traversal of the working copy during an update needs to
visit at least one file in every .svn folder (4200+ files) in 4200
different .svn folders, each with different parent folders... it is
all of this seeking that likely takes the time as much as the minimal
revision checking and tweaking.

There is a general acceptance that a more efficient and more capable
working copy format is needed - this is a massive task in design let
alone implementation and I don't even know if a serious degree of
effort has been applied to the problem given the huge push for the
upcoming 1.5 features...

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-08 13:49:19 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.