[
https://issues.apache.org/jira/browse/SVN-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693273#comment-16693273
]
Martin Kohlenberg commented on SVN-2507:
----------------------------------------
I am surprised that even after more than 12 years this problem is still not
solved...
Here in the company it often happens that the --no-unlock option is used at
commit. If files or directories are deleted at the same time, you will have a
problem later if you want to add files or directories of the same name, or if
you want to delete or rename the parent directory. The normal users do not get
the problem solved, so the admin has to act.
Please work on this issue with priority!
> '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
> Priority: Major
> 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
(v7.6.3#76005)
