You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@subversion.apache.org by "Ivan Zhakov (JIRA)" <ji...@apache.org> on 2015/10/01 19:45:26 UTC
[jira] [Updated] (SVN-2507) 'commit --no-unlock' doesn't remove
locks on files deleted
[ https://issues.apache.org/jira/browse/SVN-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ivan Zhakov updated SVN-2507:
-----------------------------
Description:
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.
was:
{noformat:nopanel=true}
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:
$ 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
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.
{noformat}
Component/s: libsvn_client
> '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)