Julian Foad wrote:
> <http://subversion.tigris.org/issues/show_bug.cgi?id=2507>
>
> This is a problem with repository locks on deleted paths. I would like
> to progress this issue because it bites our customers quite often and
> although work-arounds are possible it is quite a nuisance.
>
>
> The problematic behaviour:
>
> The repository (FS layer) tries to prevent locking a nonexistent path,
> but if you delete a locked file and commit with --no-unlock, a
> repository lock remains at the deleted path.
>
> Then the server throws an error if you later try to
> * delete the parent directory, or
> * re-create a node at the locked path.
>
> Note that while it is theoretically useful to be able to lock a
> nonexistent path, that is not a supported feature. The Subversion client
> does not attempt to keep track of locks on paths that do not exist.
>
> In issue #2507 another problem is mentioned. If a locked file is moved
> on the client side, it is then not locked at its new path. The user
> expects the lock to be moved to the new path. This should be filed as a
> separate issue as it is independent of this issue (though related) and
> has complexities of its own.
>
>
> Work-arounds:
>
> Nanually remove the lock with "svn unlock --force", and re-try the
> commit. If several paths are involved, this is unsatisfactory because
> the user only finds out about one more path for each failed commit, by
> looking at the error message.
>
> Avoid using "--no-unlock". Unsatisfactory if the commit contains other
> files that are not being deleted.
>
>
> Behavioural change required:
>
> The files in <notes/locking/> do not mention locking of non-existent
> paths or specify how --no-unlock should behave with deletes (or moves).
>
> I propose the following behaviour.
>
> Subversion should, at commit time, even with "--no-unlock",
> - delete the lock when deleting or moving a locked file;
> - fail the commit if the lock deletion is refused by the server.
>
>
> Work required:
>
> The behaviour should be enforced in libsvn_fs. In the issue, C-Mike says
> that appears not to be easy.
>
> The behaviour could perhaps be implemented in the client side. Needs
> investigation to see whether that would be practical or useful.
>
>
> Comments?
What if the lock deletion succeeds, but the commit fails? Re-lock, hoping
that succeeds and that someone else hasn't already locked the file in the
meantime? Essentially, you'd like to guarantee atomicity across two
operations, but you haven't the framework to pull it off.
As a matter of policy, we decided to disallow locks of non-existent paths in
the repository. The FS layer is failing to maintain this policy in this
(and apparently the move, too) scenario. That's why my instinct is to fix
it in the FS layer. I ... just ... don't ... know ... how ... yet.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2391030
Received on 2009-09-04 16:45:12 CEST