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

Re: --no-unlock and removed files

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2006-02-19 16:58:26 CET

Ooh, yeah, that looks like a bug. Can you file it?

On 2/18/06, Stefan Küng <tortoisesvn@gmail.com> wrote:
> Hi,
>
> Version 1.3.0:
>
> When a commit deletes a file, and the --no-unlock option is passed with
> the commit, the lock is not removed. That leaves a lock on a
> non-existing file:
>
> $ svnadmin create lockrepo
> $ svn co file:///d:/test/lockrepo lockwc
> $ cd lockwc
> $ echo test > file
> $ svn add file
> $ svn ci -m ""
> $ svn lock file
> $ svn rm file
> $ svn ci -m "" file --no-unlock
> $ echo test2 > file
> $ svn add file
> $ svn ci -m ""
> Adding file
> svn: commit failed (details follow):
> svn: Cannot verify lock on path '/file'; no matching lock-token available
>
> I'm not sure if that really intended. Of course, the above recipe isn't
> that 'real life', but imagine a commit with --no-unlock where not just
> the removed file but multiple other files are committed too, then the
> --no-unlock option makes more sense.
>
> I think in case a file gets removed from the repository, the lock should
> be removed too, no matter if the --no-unlock option is passed or not.
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 19 16:58:44 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.