On Oct 30, 2007, at 00:46, Alejandro Forero Cuervo wrote:
> I have noticed that the time an svn update on a working copy for a
> local repository (ie. one stored in the same machine, so the svn up
> won't go to the network, just use a loopback interface) varies wildly
> depends on the size of my repository (and perhaps other
> characteristics) even though it doesn't have to actually update any
> files (because the local working copy was already on the latest
> version) so I decided to ask: what's the runtime complexity of issuing
> a svn update?
>
> Does it depend on the size of the repository? The number of files on
> the repository? The number of revisions on the repository? The
> number of directories and subdirectories on the repository? And, of
> course, how does it depend on the values that it depends on (eg.
> linearly?)?
>
> If the time for the operation is, as my estimates seem to indicate,
> not constant, is there any way to bring it close to constant time
> (such as somehow running an internal "optimize" procedure on the
> repositories, specifying that subdirectories should not be locked,
> etc)?
>
> How about svn commit where the repository has only one small change in
> one small file and its path is passed as an argument?
>
> Thanks!
>
> Alejo, who is getting bitten because he thought it would be constant
> time and is now seeing some svn up take 1m+ in some repositories
> locally, even when the working copy is on the last revision.
> http://azul.freaks-unidos.net/
I believe the time varies proportionally to the number of directories
in the working copy, or in the subset of the working copy you've
indicated on the command line. Subversion has to process the
information in the .svn directory in each directory of your working
copy. The first time you run svn up it can take awhile because it has
to read the information from disk. Subsequent operations can be
quicker because the data could already be in memory in your disk cache.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 30 07:15:00 2007