Re: Bug in multipath unlock - fails on unrelated working copy locks

2008/2/15 Miller, Eric <Eric.Miller_at_amd.com>:
> Scenario:
>
> svn st wc
> L wc/dir/A
> K wc/dir/B/file1
> K wc/dir/C/file2
>
> I want to unlock file1 and file2 without messing with dir/A (for the
> moment anyways)
>
> svn unlock wc/dir/B/file1 wc/dir/C/file2
> svn: Working copy '/proj/gi1/emiller/test/svn/bugs/unlock/wc/dir/A'
> locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>
> This is a minor annoyance for my users. They (and I) don't understand
> why it is trying to get a recursive adm lock on the common parent of
> file1 and file2.
>
> The workaround would be to run svn unlock for each file individually I
> guess (or just run cleanup).
>
> I've attached a repeatable testcase, should I file a bug on this?

I dunno. "L" really only happens if you have concurrent access to the
working copy or a crash to recover from. In your real cases, which
one is it? Certainly in the latter it seems like running cleanup
first is the way to go. (And is this really just an issue with
unlock? Don't must svn commands work this way?)

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org