On Jul 9, 2009, at 7:14 AM, Branko Cibej wrote:
> Wilbert Jansen wrote:
>>
>> I tried to find this bug in the open issues on Subversion bugs, but
>> wasn’t able to find it which surprises me since I’ve seen it twice in
>> the last week. I ignored the first time, since that was on a repos
>> that I was simply testing/hacking on and without much thought removed
>> it and created a new one.
>>
>>
>>
>> The below describes how we got there as good as possible. Note: this
>> is NOT a valid reproduction schema, as in it does not result in the
>> bug. Unfortunately the second repos that had the error has been
>> deleted at this time as well.
>>
>>
>>
>> Steps taken:
>>
>> - Created the SVN repos with Visual SVN Server 1.6.4
>>
>> - A file in the repos mhf_core.jar got renamed to mhf.jar
>> and
>> was moved to another folder (the who/how is unfortunately obscure).
>> That worked, as in that the mhf.jar is present in the repos and gives
>> no issues.
>>
>> - Tried to delete the folder that contained the original
>> mhf_core.jar directly from Visual SVN manager. This gives an error
>> that I don’t have a lock on mhf_core.jar (since it was created by
>> another user. When logged in with the other user’s id and tried
>> deleting, gives an error empty token).
>>
>> - Tried deleting by checking out the contents on file
>> system.
>> The mhf_core.jar was not present in that folder.
>>
>> - Tried deleting by Tortoise version 1.6 .3 and then do a
>> commit. This does not work, it gives an error that mhf_core.jar file
>> is locked: ‘Cannot verify lock on path
>> ‘/trunk/somefolderstructure/jarfile.jar’; no username available’
>>
>> - The file does however no longer exist in repository. It
>> does not get checked out and it is not there according to the repo
>> browser.
>>
>> - The only way we found to remove this lock and delete the
>> folder was by deleting the entire repository.
>>
>>
>>
>> Hopefully this gives an idea. I’ve tried to reproduce this a few
>> times, but wasn’t able to. Not sure what is missing.
>>
>
> First, you should've sent this to the users@ list. But even before
> that,
> you should've read the Subversion documentation; specifically,
> http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.locking.break-steal
>
> You can reproduce the scenario like this:
>
> $ svnadmin create repo
> $ svn co file://`pwd`/repo wc
> $ cd wc
> $ touch foo
> $ svn add foo
> $ svn commit -m ''
> $ svn lock foo
> $ svn rename foo bar
> $ svn commit --no-unlock -m ''
> $ cd ..
> $ svnadmin lslocks repo
>
> And you can remove the stale lock like this:
>
> $ svnadmin rmlocks repo /foo
>
> This is not a bug in Subversion. Without the --no-unlock option, the
> second "svn commit" would have removed the lock on "foo". It's up to
> you
> to figur out how or why that option was used.
>
We've run into this and I would argue that it is a bug. User A doing
the
commit with --no-unlock will have no idea that their commit left
a zombie lock. Meanwhile User B attempts to checkin a new file with
the same name
at a later date runs into the "Cannot verify lock" error. It makes
no sense for
the repository to have a lock on something that doesn't exist @HEAD.
Meanwhile, see http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/remove-zombie-locks.py
This script will remove either selected or all zombie locks from a
given repository. I suppose
that until someone submits a patch to fix the original issue, the
zombie script will be necessary.
-steve
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2369399
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-09 16:18:54 CEST