subversion-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Zhakov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SVN-2507) 'commit --no-unlock' doesn't remove locks on files deleted
Date Thu, 01 Oct 2015 17:47:26 GMT

    [ https://issues.apache.org/jira/browse/SVN-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14922977#comment-14922977
] 

Ivan Zhakov edited comment on SVN-2507 at 10/1/15 5:46 PM:
-----------------------------------------------------------

Another consequence of not removing these locks is that it can result in locks on directories
when a commit replaces a file with a directory:
{noformat}
svnadmin create repo
svn import -mm repo/format file://`pwd`/repo/X
svn co file://`pwd`/repo wc
svn lock wc/X
svn rm wc/X
svn mkdir wc/X
svn ci -mm wc --no-unlock
{noformat}

Now X is a locked directory:

{noformat}
$ svn info file://`pwd`/repo/X
Path: X
URL: file:///home/pm/sw/subversion/obj5/repo/X
Relative URL: ^/X
Repository Root: file:///home/pm/sw/subversion/obj5/repo
Repository UUID: 54a02543-7c52-41b1-aeb3-bdab691dd3e6
Revision: 2
Node Kind: directory
Last Changed Author: pm
Last Changed Rev: 2
Last Changed Date: 2015-09-24 22:56:51 +0100 (Thu, 24 Sep 2015)
Lock Token: opaquelocktoken:2b9e70e9-d592-4be8-a0d0-fe6d3b2c7837
Lock Owner: pm
Lock Created: 2015-09-24 22:56:51 +0100 (Thu, 24 Sep 2015)
{noformat}

and that leads to things like:

{noformat}
svn co file://`pwd`/repo wc
svn ps p v wc/X
svn ci -mm wc
svn: E195022: Directory '/home/pm/sw/subversion/obj5/wc/X' is locked in another working copy
{noformat}



was (Author: philipm):
{noformat:nopanel=true}
Another consequence of not removing these locks is that it can result in locks
on directories when a commit replaces a file with a directory:

svnadmin create repo
svn import -mm repo/format file://`pwd`/repo/X
svn co file://`pwd`/repo wc
svn lock wc/X
svn rm wc/X
svn mkdir wc/X
svn ci -mm wc --no-unlock

Now X is a locked directory:

$ svn info file://`pwd`/repo/X
Path: X
URL: file:///home/pm/sw/subversion/obj5/repo/X
Relative URL: ^/X
Repository Root: file:///home/pm/sw/subversion/obj5/repo
Repository UUID: 54a02543-7c52-41b1-aeb3-bdab691dd3e6
Revision: 2
Node Kind: directory
Last Changed Author: pm
Last Changed Rev: 2
Last Changed Date: 2015-09-24 22:56:51 +0100 (Thu, 24 Sep 2015)
Lock Token: opaquelocktoken:2b9e70e9-d592-4be8-a0d0-fe6d3b2c7837
Lock Owner: pm
Lock Created: 2015-09-24 22:56:51 +0100 (Thu, 24 Sep 2015)

and that leads to things like:

svn co file://`pwd`/repo wc
svn ps p v wc/X
svn ci -mm wc
svn: E195022: Directory '/home/pm/sw/subversion/obj5/wc/X' is locked in another
working copy

{noformat}


> '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)

Mime
View raw message