Re: svn 1.7 - switching from file to directory external

Sofie De Cooman <svn_at_sofiedc.be> writes:

> 1. checkout directory a recursively and locally apply an svn:externals
> property on it:
> /b/test.txt b/test.txt

Here you are setting svn:externals on the parent of the versioned
directory b that puts an external node inside b. It's not clear that we
ever intended to support that.

> perform an svn update on a => test.txt gets loaded in versioned subdirectory b
>
> 2. now locally exclude subdirectory b from update (svn update b
> --set-depth=exclude), which removes versioned subdirectory b from the
> local working copy
> 3. change the local svn:externals property set on a to become a
> directory external:
> /b b

Here you are changing the svn:externals so that the external node is at
the same location as a versioned directory. When you try to checkout
the external and the versioned directory will obstruct each other:

$ svnadmin create repo
$ svn mkdir -mm file://`pwd`/repo/A
$ svn mkdir -mm file://`pwd`/repo/B
$ svn co file://`pwd`/repo wc
$ svn ps svn:externals '^/B B' wc/A
$ svn ci -mm wc

That's a very nomal svn:externals setup. Now add ^/A/B and try and
checkout:

$ svn mkdir -mm file://`pwd`/repo/A/B
$ rm -rf wc
$ svn co file://`pwd`/repo wc
$ svn st wc
    S wc/A/B

wc/A/B should not be switched.

> 4. perform an svn update on a
> => the directory external gets loaded, but you also get the
> following error (which didn't occur in svn 1.6)
>
> Removed external 'b\test.txt': The node '<local path>\a\b\test.txt' is
> not an external.
> svn: warning: W200000: Error handling externals definition for 'b\test.txt':
> svn: warning: W155010: The node <local path>\a\b\test.txt' is not an external.
> Updated to revision 16.
> svn: E205011: Failure occurred processing one or more externals definitions
>
> ---> Seems as if svn also still tries to remove the file external,
> which fails as subdirectory b now comes from the directory external
>
> -> This error remains during further updates of a
>
> Can this be considered a bug or is this intended behavior?

I don't suppose there is any intended behaviour because we never
intended to support it. We should probably make Subversion do something
"sensible" but what is "sensible"? Perhaps we should not process
svn:externals where the path overlaps a versioned child?

-- 
Philip