svn:switch doesn't work with relative svn:external?

Question

We have a subfolder that is a relative svn external (../project/subfolder). In a fresh trunk checkout it points to (...TRUNK/project/subfolder) and in a fresh branch checkout it points to (...BRANCH/branchName/project/subfolder). But if you do a switch on the project containing the subfolder, the subfolder stays pointing at TRUNK. Alternately if you do a BRANCH checkout and switch to TRUNK it stays pointing at BRANCH.

Shouldn't an svn:switch update relative externals? Is there some sort of recursive svn:switch I should be running?

Answer 1

The correct answer to the question is "yes, it should update those externals." The fact that it does not is a bug:

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

Fix target milestone is 1.6.10. The fix is apparently completed, but the current release version as I write this is still 1.6.6.

Answer 2

Alas, I believe this is still not fixed, despite that the bugfix mentioned above was implemented a long time ago.

I have an externals whose name has embedded spaces and uses a double relative path. My external references a file in the same branch but over and down, like so: ../../myOriginFolder/itsSubfolder/my file name.pdf

Once I renamed the branch, now my repo is broken using TortoiseSVN 1.7.8 (or its commandline SVN 1.7.6). The old working copy cannot be updated correctly after its switch, nor can I checkout a fresh copy of the old-named branch! All of the commands - checkout-to-old-revision, update-to-old-revision and switch-and-update - will fail. The only thing that works ok is to do a fresh checkout and then move ahead, never back.

This seems like a pretty bad bug! It means that as a result of my using the relative path externals, I can no longer rename/switch/revert my branches.

I wonder if anyone has seen this and has a workaround? I'm wondering if I should just hard-code those references. Even that might be better than this failure.

I wonder also if the fix referenced above may now be failing because between 1.6 and 1.7 the working copy format was changed. Now there is only one top level breadcrumb; possibly that could relate to the issue? If I could still checkout that folder, I'd compare the /.svn/ info for that fresh checkout of latest vs for prior name.

Here are the details of the error I see.

TortoiseSVN says : External failed c:\myRepo-keyword\myDestinationFolder\my file name.pdf Error Report of '/svn/myrepo/!svn/me': Could not read chunk size :connection was closed by server.

Apache/VisualSVN event log says; Source: VisualSVN Server 2.5 Date: 8/21/2012 11:20:57 AM Event ID: 4000 Level: Information Description: switch /myRepo-Path/myOriginFolder/itsSubfolder/my file name.pdf/my file name.pdf /myRepo-Path/mySubfolder/my file name.pdf@7178

Here is the error from a fresh checkout of the external-ed folder from a revision prior to the rename. External failed: C:\VcsSvn\3.7.8.6328.RuntimeRefs\Stroz Review User Guide.pdf
Error: URL
Error: 'http://myurl/svn/myOldRepo-Path/myOriginFolder/itsSuubfolder/my file name.pdf'
Error: at revision 7179 doesn't exist
Completed: At revision: 6328

//edit Thanks to another stackoverflow user, I found this open ticket that may be related; http://subversion.tigris.org/issues/show_bug.cgi?id=4150

//edit2; Another poster recommends avoiding externals: How can I branch in SVN and have it branch my svn:external folders as well?

Answer 3

Seems like this was fixed in Subversion 1.6.11 http://svn.apache.org/repos/asf/subversion/trunk/CHANGES

Answer 4

You may want to try svncopy.pl. svn:externals are not updated when you branch or switch.

Answer 5

Subversion generally considers externals to be separate from their containing project. For example, "svn commit" only looks at files in the project, not at any files in externals contained within the project. "svn switch" works the same way; you can switch the main project, but you'll need to run a separate "svn switch" on each external.