Re: Coniguring 301/302 redirects to track an fspath rename

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 > > > >
Received on 2013-02-05 17:57:54 CET