Hi....
cmpilato@localhost.localdomain wrote on 22.10.2003 17:05:04:
> 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.
Ah.... I see. That will explain this....
Thanks,
Roland, hoping for 0.33(?)
---------------------------------------------------------------------
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:21:06 2003