[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bug: Lock on a file that is no longer existing.

From: Branko Cibej <brane_at_xbc.nu>
Date: Thu, 09 Jul 2009 13:14:48 +0200

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,

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

Received on 2009-07-09 13:15:31 CEST

This is an archived mail posted to the Subversion Dev mailing list.