I apologize if this has been reported before, or if it's in the wrong
place, but I was wondering if this issue is considered a bug:
I've recent moved a bunch of SVN repositories from one server to
another, with some additional URL path changes. I've set up permanent
redirects from the old to the new, which does well for general HTTP(S)
access/browsing.
My hope was that when I update a working copy, the redirect would
perform the relocate automatically, or at least help the user do so
(with a prompt.) This actually does appear to work well if the working
copy was checked out from the root of the repository.
My problem is that (per convention) I have the trunk/tags/branches at
the root and usually checkout the /trunk, so most of my working areas
are not checked out at the root. So, for an 'svn update' I get:
c:\svn>svn --version
svn, version 1.8.5 (r1542147)
compiled Nov 24 2013, 13:00:38 on x86-microsoft-windows
c:\svn>svn update dfis
Updating 'dfis':
Redirecting to URL 'https://new.server.com/svn/public/dfis/trunk':
svn: E155024: Invalid relocation destination:
'https://new.server.com/svn/public/dfis' (does not point to target)
But I can simply do this (keep in mind c:\svn\dfis is the /trunk)
c:\svn\dfis>svn relocate https://old.koronisbiotech.com/public/svn/dfis
https://new.server.com/svn/public/dfis
and things work just fine.
So, I ask: Why can't the svn update figure this out? The redirect has
the root URL in it, with '/trunk' added, and knows the working copies
old root URL, so couldn't it just remove the '/trunk' from the
redirected/new URL and still do the relocate (just as if it had done the
command above?)
This seems to me like an easy/straightforward modification and would
save me (and many others) lots of time. Personally, I can write a
script to do this using the output of 'svn info' and my knowledge of
what I've moved, but I can't easily get everyone able to run these sorts
of scripts. Having the a non-root checkout redirect relocate the root
seems ideal to me--it follows the users standard flow and they can be
(almost) none-the-wiser.
Cheers!
-Shane
