[
https://issues.apache.org/jira/browse/SVN-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15141710#comment-15141710
]
Philip Martin commented on SVN-2507:
------------------------------------
Ideally the lock removal would be part of the atomic commit but that is really
hard to implement. As an interim measure perhaps we should make the server
remove the locks non-atomically, much as it removes locks for commits that
remove all locks. The server is in a position to do this efficiently: it has
the lock tokens and can determine which paths were deleted in the new revision.
> 'commit --no-unlock' doesn't remove locks on files deleted
> ----------------------------------------------------------
>
> Key: SVN-2507
> URL: https://issues.apache.org/jira/browse/SVN-2507
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_client, libsvn_fs
> Affects Versions: 1.3.x
> Reporter: Stefan Küng
> Fix For: unscheduled
>
>
> As reported here:
> http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=433823
> Filing issue with permission of Ben Collins-Sussman:
> When a commit deletes a file, and the --no-unlock option is passed with the
> commit, the lock is not removed. That leaves a lock on a non-existing file:
> {noformat}
> $ svnadmin create lockrepo
> $ svn co file:///d:/test/lockrepo lockwc
> $ cd lockwc
> $ echo test > file
> $ svn add file
> $ svn ci -m ""
> $ svn lock file
> $ svn rm file
> $ svn ci -m "" file --no-unlock
> $ echo test2 > file
> $ svn add file
> $ svn ci -m ""
> Adding file
> svn: commit failed (details follow):
> svn: Cannot verify lock on path '/file'; no matching lock-token available
> {noformat}
> I'm not sure if that really intended. Of course, the above recipe isn't that
> 'real life', but imagine a commit with --no-unlock where not just the removed
> file but multiple other files are committed too, then the --no-unlock option
> makes more sense.
> I think in case a file gets removed from the repository, the lock should be
> removed too, no matter if the --no-unlock option is passed or not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
