Julian Foad wrote:
>> Would it not have been sufficient to just lock infinitely on an as-needed
>> basis (like, when a directory deletion comes across the wire)? (And is that
>> trivially do-able?)
>
> I don't think it's possile to request a new recursive lock on a tree
> that's already partially write-locked, and at least the root of this
> tree is write-locked. If you mean something better than what I'm doing
> and that could work in the light of this explanation, please speak up.
So, it's been a long while since I even typed "adm_access" in our source
files, but I thought for sure that you can sort of "append" new write locks
to a given existing collection of locks held in an adm_access baton. So,
for example, if you need to delete /some/sub/dir and you already have locked
as deeply as /some/sub/dir, you just add to the lock set the children of
/some/sub/dir. If you locked more deeply, you add to the lock set just the
stuff that needs to be locked but wasn't. (And I'd suggest that there
probably could stand to be new svn_wc_adm_* function to do this sort of
magic if such doesn't exist already -- there's no good reason for a given
process to be tripping over its *own* write locks, is there?)
Granted, this is all quite a bit more complicated than the more naive
approach your change reverted us to.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-10-15 11:21:38 CEST