subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: Coniguring 301/302 redirects to track an fspath rename
Date Tue, 05 Feb 2013 16:57:18 GMT
Then frankly we didn't address the ticket
properly because that Redirect Jon Stevens
mentioned was within the same svn repository,
so a relocate operation was always the "wrong"
solution to begin with.






>________________________________
> From: C. Michael Pilato <cmpilato@collab.net>
>To: Greg Stein <gstein@gmail.com> 
>Cc: Joe Schaefer <joe_schaefer@yahoo.com>; "dev@subversion.apache.org" <dev@subversion.apache.org>

>Sent: Tuesday, February 5, 2013 10:07 AM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
> 
>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 <cmpilato@collab.net>
>CollabNet   <>  www.collab.net   <>   Enterprise Cloud Development
>
>
>
>
Mime
View raw message