On 02/04/2013 10:57 PM, Greg Stein wrote: > Better handling of redirects was released in 1.7.0. > > See: http://subversion.tigris.org/issues/show_bug.cgi?id=2779 and the > CHANGES file. > > The working copy is not relocated, however. Just the error report. The > user needs to follow up with some action. Other clients (eg > TortoiseSVN) could theoretically perform an auto relocation, but the > cmdline client does not. > > Cheers, > -g
That's not ... entirely ... true. In 1.7, I actually did teach Subversion's update functionality to automatically relocate the working copy if the server sends a permanent redirect during whatever requests comprise the svn_ra_open() handling. The problem I see with all of the chatter in this thread is that 'relocate' is precisely the *wrong* action for the user to take. If the repository directory has simply been moved to some other place in the same repository, this calls for a regular 'svn switch'. Relocation is a metadata-only transformation within the working copy, which tweaks the repos_root_url and repos_relpath as a way of dealing with the situation where a whole repository has been moved to/exposed at a different URL. You need something here that operates *within the same repository* and which traverses not just space (URLs) but time also (revisions). That's 'svn switch'. We have no client-side automated support for 'svn switch'ing to a new location. So, I hate to be the bearer of bad tidings, but this entire exercise is a giant waste of time and energy. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
