Leandro,
Yes this is a bug as of 1.4.2. I think the issue is that when you commit a
deletion of a file having a lock, the server doesnšt automatically clear the
lock that is present in the repository. The annoying thing is that because
locks are unrevisioned, they sit off to the side in the repository. Here is
the sequence of events:
User A:
% svn lock dir1/file1
% svn rm dir1/file1
% svn ci dir1/file1
If you query the repository using Œsvnlook lock <url-path-for-file1>š,
youšll see that a lock still exists for this file even though the file is
non-existent in the HEAD revision. In my view, committed deletions should
automatically clear the lock. The bug we ran into is that after the above
sequence, we attempted to do this:
User B:
% touch dir1/file1
% svn add dir1/file1
% svn ci dir1/file1
At this point we get an error saying that User B does not own the lock on
file1 even though file1 does not exist in the HEAD revision!
-steve
On 5/3/07 10:30 AM, "Leandro Silva" <leandroswquality@gmail.com> wrote:
> I am having this problem:
>
> There is a lock at one file, but this file was deleted at some revision in the
> past. I am trying to delete the folder of this file and the SVN return this
> error:
> "User user1 does not own lock on path '/folder/file.doc' (currently locked by
> user2)"
>
> Anyone knows if this is a bug?
>
> The server runs Subversion 1.4.0
Received on Thu May 3 18:39:12 2007