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.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2369345
Received on 2009-07-09 13:15:31 CEST