Hi.
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/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 30 06:46:43 2007