[
https://issues.apache.org/jira/browse/SVN-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14922952#comment-14922952
]
Ivan Zhakov edited comment on SVN-2507 at 10/1/15 5:48 PM:
-----------------------------------------------------------
For people working mainly with unlocked files this is a minor issue, but for
people working on unmergable data all the time where they always must have
locks, this is a *SERIOUS PROBLEM*.
We have a team of tech writers working on unmergable binary FrameMaker files.
They always must keep locks on the files so with every commit they use
--no-unlock. They are constantly hitting this bug, where they cannot delete a
directory or cannot commit a new file because of hidden locks on files long
deleted. They use gui clients and cannot be expected to 'svn unlock --force
URL-to-nonexistant-file' for every deleted-but-locked-file (which they can only
find the names of one-by-one, every time they attempt a commit). For these tech
writers they often make large commits where files are deleted and many others
modified, so they need to use --no-unlock.
For this use case the behaviour that makes sense is if a file is deleted then
remove the lock, even if --no-unlock is specified.
Original comment by *nathankidd*
was (Author: subversion-importer):
{noformat:nopanel=true}
For people working mainly with unlocked files this is a minor issue, but for
people working on unmergable data all the time where they always must have
locks, this is a *SERIOUS PROBLEM*.
We have a team of tech writers working on unmergable binary FrameMaker files.
They always must keep locks on the files so with every commit they use
--no-unlock.
They are constantly hitting this bug, where they cannot delete a directory or
cannot commit a new file because of hidden locks on files long deleted. They
use gui clients and cannot be expected to 'svn unlock --force
URL-to-nonexistant-file' for every deleted-but-locked-file (which they can only
find the names of one-by-one, every time they attempt a commit).
For these tech writers they often make large commits where files are deleted and
many others modified, so they need to use --no-unlock.
For this use case the behaviour that makes sense is if a file is deleted then
remove the lock, even if --no-unlock is specified.
{noformat}
Original comment by *nathankidd*
> '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)
