Roland Schwingel <Roland.Schwingel@onevision.de> writes:
> > I'm guessing this is issue #1245. While you are incorrect in assuming
> > that your whole tree is checked for changes, we *do* have a known bug
> > that would cause practically your whole tree to be *locked* (and later
> > unlocked) during the commit process. This can take a long time.
> Well you are the guru... :-)
>
> What I have observed is, that my harddrive works like mad when doing my
> mentioned action. And the bigger my repos is the longer it takes.
> (I tried the same with smaller versions). So I was thinking it
> might run here thru the whole tree, whereas it is not doing that when
> doing single checkins.
Oh, sure, your harddrive will go to town. To lock a working copy
means recursively reading the entries file for the whole thing,
writing lockfiles in all the .svn directories, etc. What you should
be seeing is that the cost in time is not so much about the size of
your repository, but the distance between your two paths. They way it
works is that if you commit two paths by name, (say A/B/C/foo and
A/B/D/E/bar), the parent of the longest common ancestor of the set of
the paths (in this case A, the parent of A/B) is locked.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 22 17:06:24 2003