On Mon, 5 Dec 2005, Garrett Rooney wrote:
> So back in r15015 lundblad split the repos root and fs path in the
> working copy code, and along with that added some sanity checking to
> confirm that the url and copyfrom url fields were always under the
> repos root, since why would they ever not be?
> Well, it turns out that with suitably configured DNS (a repos that
is > accessible via two separate DNS entries) and a user equiped with svn
> switch, you can actually get a working copy wiht disjoint repos and
> url entries. Just check out via one DNS entry and then switch a
> subdirectory to the other. This is problematic because it trips the
I tried to reproduce this with ra_local and first checking out with
and then switching subdir to something like
That gives an error with svn 1.2.4 and trunk. Can you provide a recipe?
> assert at libsvn_wc/entry.c:71, and even when you replace the assert
> with an error check you still aren't all the way there, because even
> after the error is returned you still end up with a busted working
> copy. If you leave the assert it's even worse, because you now have a
> locked working copy and svn cleanup refuses to unlock it because it
> freaks out about the weird repos/url problem.
The assert just checks that the caller knows what it's doing. The real
problem is higher up the call stack.
> This is particularly bad because this code is in 1.3.0rc4, and that
> means we are not compatable with some (very weird) working copies out
> in the wild.
Was the WC in this state before starting to use 1.3.0, or does 1.3.0 allow
the WC to enter this state?
> I've looked into the problem a little, but I'm really not sure what
> the correct solution is. Should we disallow such things? If so, we
> need to make sure that the error case doesn't result in a busted
> working copy, and we need to decide what to say to users who have
> working copies like this. If we don't want to support such things, we
> need to at least provide a work around (svn switch --relocate seems
> like it should fix things, if we can keep it from going bonkers when
> it notices that the working copy is in this weird state).
I want to look into this, but you need to describe it further. What
command triggers the assert?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Dec 6 09:56:20 2005