On Fri, 2009-09-04, C. Michael Pilato wrote:
> 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?
No, if we do it client-side we would do it the other way around: commit,
then (if the commit succeeds) unlock any paths that were deleted in the
commit. That's not atomic but it's an automation of the work-around that
I assume we would recommend, and seems quite pragmatic.
> Essentially, you'd like to guarantee atomicity across two
> operations, but you haven't the framework to pull it off.
Right: on the client we can only do a work-around. The only reasons we'd
want to do a client-side work-around would be (a) if a proper
server-side fix is too difficult to do any time soon, or (b) to get a
quicker fix for people running into this problem who can't update their
server any time soon but who can update their clients more quickly.
> 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.
I don't know the FS layer yet but I believe you when you say it's hard.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2394522
Received on 2009-09-14 12:46:35 CEST