[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS update: MODIFIED: libsvn_wc ...

From: <cmpilato_at_collab.net>
Date: 2001-08-30 20:56:31 CEST

I think I sent this just to Greg by accident earlier this morning.
Now, I share it with all of you for your knowledge-enhancement
benefit. Note that because I failed to send it to the list in the
first place, Ben actually *did* respond to Greg's message. :-)


Greg Stein <gstein@lyra.org> writes:

> Why would we try to lock a directory twice? I had thought our algorithm was
> very strict about how it visited items, so there shouldn't be a visit to the
> same directory twice. Assuming that is true, then this patch would be
> covering up a more fundamental and deeper bug.

Well, shoot, I was hoping Ben would respond to this, but oh well. :-)

I definitely freaked out too when I saw this going on, but the
explanation is rather simple. Basically, it boils down to some
misunderstandings about how our commit target sorting works.

Given these targets:
The sort algorithm, unlike what Ben and I both seemed to think, does
NOT do a "dirs first" approach--it simply sorts paths, promising that
children of the same parent will be grouped.

So, the output of this sort would be:



As you can see, this means when we commit `contact.html' we will lock
its parent directory, `/'. The we do `docs/biography.pdf' and
`docs/mailinglist.txt', and we lock `docs/'. Finally, we come to
`orderform.html', and we need to lock `/' -- but it has already been

If the sorting algorithm promised to put grandchildren of a given
parent above their...uncles and aunts? (a dirs-first sorting) then we
wouldn't run into this. But that's not required by the editor.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:37 2006

This is an archived mail posted to the Subversion Dev mailing list.