You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Peter Suter <pe...@lucid.ch> on 2014/03/25 14:45:57 UTC

Lock bug? Own lock breaks on update

Hi,

(I asked about this on IRC today and was asked to send a repro to this
list.)

Since updating to TortoiseSVN 1.8 my locks get broken when I update a
repository. (Downgrading to TortoiseSVN 1.7.13 fixes it. Upgrading back
to 1.8.0 or 1.8.5 (the latest, based on Subversion 1.8.8) makes the
problem reappear. With the SlikSvn command line client 1.8.5-x64 I also
get the same problem.)



I can reproduce it with a new empty repo on that server (VisualSVN 2.1.7
32bit, based on Subversion 1.6.16):

C:\Repos> svnadmin create testrepo

C:\Repos>

And then on the client (using SlikSvn command line client 1.8.5-x64
here, but the same happens with TortoiseSVN):

C:\> svn co https://.../testrepo testrepo
Checked out revision 0.

C:\> cd testrepo

C:\testrepo> echo foo > foo

C:\testrepo> svn add foo
A          foo

C:\testrepo> svn ci -mm
Adding          foo
Transmitting file data .
Committed revision 1.

C:\testrepo> svn lock foo
'foo' locked by user 'peter'.

C:\testrepo> svn update
Updating '.':
B    foo
updated to revision 1.

C:\testrepo>


I could not reproduce the problem with a local file:/// repo created
with TortoiseSVN on the client.

Thanks,
Peter

Re: Lock bug? Own lock breaks on update

Posted by Philip Martin <ph...@wandisco.com>.
Peter Suter <pe...@lucid.ch> writes:

> (I asked about this on IRC today and was asked to send a repro to this
> list.)
>
> Since updating to TortoiseSVN 1.8 my locks get broken when I update a
> repository. (Downgrading to TortoiseSVN 1.7.13 fixes it. Upgrading back
> to 1.8.0 or 1.8.5 (the latest, based on Subversion 1.8.8) makes the
> problem reappear. With the SlikSvn command line client 1.8.5-x64 I also
> get the same problem.)
>
>
>
> I can reproduce it with a new empty repo on that server (VisualSVN 2.1.7
> 32bit, based on Subversion 1.6.16):
>
> C:\Repos> svnadmin create testrepo
>
> C:\Repos>
>
> And then on the client (using SlikSvn command line client 1.8.5-x64
> here, but the same happens with TortoiseSVN):
>
> C:\> svn co https://.../testrepo testrepo
> Checked out revision 0.
>
> C:\> cd testrepo
>
> C:\testrepo> echo foo > foo
>
> C:\testrepo> svn add foo
> A          foo
>
> C:\testrepo> svn ci -mm
> Adding          foo
> Transmitting file data .
> Committed revision 1.
>
> C:\testrepo> svn lock foo
> 'foo' locked by user 'peter'.
>
> C:\testrepo> svn update
> Updating '.':
> B    foo
> updated to revision 1.
>
> C:\testrepo>
>
>
> I could not reproduce the problem with a local file:/// repo created
> with TortoiseSVN on the client.

I think that is issue 4412:

http://subversion.tigris.org/issues/show_bug.cgi?id=4412

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*