Re: Locking Bugs?

Bill Mill wrote:
> 2) What exactly is going on here? Shouldn't a file's lock expire (at
> least for future revisions) when it's deleted? What use can there be of
> keeping that lock around to haunt users in the future?

Locks are not tied to specific revisions. And according to the design
principles of Subversion's locking stuffs, locks on non-existent-in-HEAD
paths are expressly disallowed. So yes, it seems like making locks expire
when their paths are deleted should be something that the repository code
enforces instead of the current situation, which is (I believe) that the
client code is responsible for removing all those locks (which is error-prone).

There are some complications with this recommendation, unfortunately, namely
that we now have lock deletion and commit completion needing share the same
atomicity protection. But I guess we the Subversion devs just have to
figure out how to deal with that. :-)

By the way, does http://subversion.tigris.org/issues/show_bug.cgi?id=2507
work as an adequate description of the problem you are seeing?

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand