> > Ahh, linear on the number of subdirectories in the working copy
> > because it has to process the .svn subdirectory of each.
> >
> > Does the amount of time it takes to process each .svn subdirectory
> > depend on the number of files in its corresponding directory? If so,
> > I suppose it will turn out to be linear on the number of files instead
> > of on the number of directories (so placing all files in the root
> > wouldn't really help things).
>
> Also, due to the way the update code is written, a recursive update is
> much faster than one specifying a list of target files (at least for the
> time being).
Oh. I wasn't thinking of specifying a list of target files, but
wondering whether the time it takes to update (without specifying any
files) a local working copy that is already in the latest revision
depends linearly on the number of directories or on the number of
files in the repository (or, although I'd think this is unlikely, on
the sum of the sizes of the files?).
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.
The reason I'm asking is because I have noticed that Svnwiki is taking
a lot of time to complete some operations. Profiling it, I found that
most of that was spent waiting for calls to Subversion's libsvn_client
to return. So I'm really trying to see if I can improve the way
Svnwiki uses Subversion so Svnwiki users won't have to wait for long
operations to complete (instead of having to change Svnwiki's default
content management system).
Thanks for your replies! :-)
Alejo.
http://azul.freaks-unidos.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 31 00:12:00 2007