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

Thanks Greg, that clears things up for me. >________________________________ > From: Greg Stein <gstein@gmail.com> >To: Joe Schaefer <joe_schaefer@yahoo.com> >Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >Sent: Monday, February 4, 2013 10:57 PM >Subject: Re: Coniguring 301/302 redirects to track an fspath rename > >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 > > >On Mon, Feb 4, 2013 at 10:41 PM, Joe Schaefer <joe_schaefer@yahoo.com> wrote: >> Has Daniel been pulling my leg this whole time >> about this automatic relocation feature?  I don't >> see any mention of it on the website for the 1.7 >> docs and have tested through 1.7.3 without seeing >> it work. >> >> If there's work here that needs doing on >> the subversion side I apologize for all the noise >> I've generated, I thought this was a feature you >> were already supporting on some level and was anxious >> to take advantage of it. >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Monday, February 4, 2013 8:15 PM >> >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> Ok folks, some butt ugly code I wrote is fishing >> the source url out of the REPORT request body on >> update requests.  If I checkout revision 1400000 >> of >> >> http://svn.apache.org/repos/asf/incubator/openmeetings/trunk/singlewebapp >> >> that works fine, but then when I try to run >> >> $ svn up >> >> on that working copy, I get the following error: >> >>  svn: E175011: Repository moved permanently to >>  'https://svn.apache.org/repos/asf/openmeetings/trunk/singlewebapp'; >>  please relocate >> >> Honestly that's an improvement, but not what I'm looking >> for here: I need a way for the client to autoswitch to the >> new location, not merely prompt the user to do it manually. >> This is with svn 1.7.0, maybe things have changed since then? >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Monday, February 4, 2013 4:48 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> Damn, processing updates requires fishing little >> details out of a REPORT request body.  This is getting >> complicated... >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Monday, February 4, 2013 3:57 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> Here's the new section for the additional PROPFIND >> rewrite block: >> >> /* RewriteCond %{SUBREQ} =false >> */ >> /* RewriteCond %{REQUEST_METHOD} =PROPFIND >> */ >> /* RewriteCond %{REQUEST_URI} >> /repos/asf/!svn/(?:bc|rvr)/(\d+)/incubator/(.+)*/ >> /* RewriteCond /repos/asf/%2?ckpath  -U >> */ >> /* RewriteRule .* /repos/asf/%2 [L,R=301] >> */ >> >> >> As I said it works for me with openmeetings checkouts >> out of incubator (1.6 and 1.7 clients point me at the >> new location).  I am leery tho about dorking with !svn >> based urls but these !svn/bc/$revision and !svn/rvr/$revision >> ones are nice candidates because of the embedded revision >> and path information that leads me to think I'm not too >> far off in guessing that without interception by my module >> we'd just be serving up 404's for them when they are looking >> in the incubator tree for graduated podling resources. >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Monday, February 4, 2013 2:44 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> Mixed news- I hacked together PROPFIND support >> for my module and it's doing the "right thing" >> on checkouts with 1.6 and 1.7. NFI what else this >> breaks, but if folks could beat on incubating repos >> for a bit to see I'd appreciate it. >> >> Thanks! >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Monday, February 4, 2013 1:46 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> Oh damn, sigh.  I'm completely wrong- subversion doesn't >> serve a 404 on the OPTIONS request, even for a resource >> that's not present in HEAD.  It serves a 200 response, >> and only several PROPFIND's later do we actually serve >> a showstopping 404 on a checkout for a non-existent resource. >> >> That complicates this situation significantly, sorry. >> I don't see an immediate way to satisfy the ASF's use >> case given the current svn support for redirects revolves >> around the initial OPTIONS response not PROPFINDS. >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Monday, February 4, 2013 1:30 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> Please correct me if I'm mistaken, but my impression >> from looking at server logs is that there are certain >> cases where a 404 response to an initial OPTIONS request >> is a showstopper (like a checkout or update operation), >> but other times the 404 response is not a problem (like >> for operations involving pegrevs).  If we can identify >> this distinction and flag it somehow in the initial request >> so that in the first case we ask for a non-showstopper >> response from the server if available, that's all I need >> to support the ASF's use case in my module.  Providing >> additional version info in the query string can refine >> the server response my httpd module would provide, but >> that aspect is not essential to service the ASF's needs. >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Monday, February 4, 2013 12:26 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> How about a "prefer redirect" flag somewhere in >> the OPTIONS request?  Anything to signal to the >> server that the request wants something better >> than a 404 response it possible. >> >> >> ________________________________ >> From: Greg Stein <gstein@gmail.com> >> To: Joe Schaefer <joe_schaefer@yahoo.com> >> Cc: dev@subversion.apache.org >> Sent: Monday, February 4, 2013 7:44 AM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> Yeah... I think the best we can do in the OPTIONS is to hint. It can't >> really be more than a hint, since a connection can be used for N various >> operations. >> What might be more ideal is to respect redirects after that initial OPTIONS. >> Then your module could just wait until it knows the right data. >> It's not an easy problem. If we get a 301, then we should definitely rewrite >> the working copy to use the new URL. But... is a 301 correct, if "old" >> revisions still work? .... >> Cheers, >> -g >> On Feb 3, 2013 2:33 PM, "Joe Schaefer" <joe_schaefer@yahoo.com> wrote: >> >> We don't actually need the subversion server >> to do anything useful with the query string >> on an OPTIONS request.  We just need it as >> a hint for http server admins, combined with >> a (global) configuration option to tell our >> working copies to autoswitch when they see a >> 301 on the initial OPTIONS response. >> >> Sorry if this is getting boring.  In no way is >> it essential, but we have significant working copy >> investments in incubating projects that are a pain >> to manage administratively right now whenever a project >> graduates.  Anything along these lines to cut down >> on the human labor aspects would be most welcome. >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Sunday, February 3, 2013 1:45 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> IOW the easiest way for us to support OPTIONS >> requests with this module, which would require >> no code changes to the module I wrote, is for the >> initial OPTIONS request to hang a ?p=whatever >> query string onto the request whenever it's dealing >> with pegrevs. >> >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Sunday, February 3, 2013 1:04 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> A few urls to fetch to get the basic idea: >> >> http://svn.apache.org/repos/asf/incubator/openmeetings/trunk >> (will redirect) >> >> http://svn.apache.org/repos/asf/incubator/openmeetings/trunk?p=1400000 >> (won't redirect) >> >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Sunday, February 3, 2013 12:15 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> The code is here if you are interested (dunno >> if it's publicly accessible or not but I believe >> so). >> >> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/ >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Sunday, February 3, 2013 12:10 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> I backed off with the idea of trying to coax >> new behavior out of svn clients by munging OPTIONS >> responses, but GET and HEAD are now doing >> interesting things even with ?p= set.  For our >> purposes someday it would be nice to just have >> a graduating podling's checkouts all auto-switch >> to the moved location.  Whether that's >> accomplished by augmenting an OPTIONS request >> with revision details or just using the existing >> GET/HEAD support or some other method would be >> just fine with me. >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: Greg Stein <gstein@gmail.com> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Saturday, February 2, 2013 2:07 AM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> The (pegrev) revision is typically available on >> the command-line: all I want is for svn to distinguish >> between >> >>    svn ls foo@1000000 >> >> and >> >>    svn ls foo >> >> as far as making redirects pegrev-aware. >> >> >> ________________________________ >> From: Greg Stein <gstein@gmail.com> >> To: Joe Schaefer <joe_schaefer@yahoo.com> >> Cc: dev@subversion.apache.org >> Sent: Saturday, February 2, 2013 1:53 AM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> Oh, and to the second part: the code which sends OPTIONS has no knowledge >> about the future operations. There is no way to send <revision/>, or >> similar. *Very* disconnected, as in: not even cheesy-hackable. >> Cheers, >> -g >> On Feb 2, 2013 1:49 AM, "Greg Stein" <gstein@gmail.com> wrote: >> >> That OPTIONS request is generic, and contains no information about the >> future operation(s) that will be performed on the connection. It is used for >> the client to validate and gather information about the server. >> Cheers, >> -g >> On Feb 2, 2013 1:23 AM, "Joe Schaefer" <joe_schaefer@yahoo.com> wrote: >> >> So I now see the request body (xml payload) >> in the OPTIONS request, but nothing there nor >> in the headers tells me about revision numbers. >> If I can convince you to add a <revision/> block >> to the OPTIONS request body I can handle the rest >> from the httpd side.  Obviously this won't help >> existing clients, but hey it's a gee-whiz feature >> anyhow. >> >> >> >> ________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >> To: 'Daniel Shahaf' <d.s@daniel.shahaf.name>; Bert Huijben <bert@qqmail.nl> >> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> >> Sent: Friday, February 1, 2013 9:26 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> So I have this implemented about as well >> as I can with what I know about OPTIONS >> requests that svn generates.  It would >> help if I knew how svn supplies revision >> information in the OPTIONS request headers >> so I can pass that along to the codebase >> instead of always using the youngest rev. >> >> >> ________________________________ >> From: 'Daniel Shahaf' <d.s@daniel.shahaf.name> >> To: Bert Huijben <bert@qqmail.nl> >> Cc: dev@subversion.apache.org >> Sent: Friday, February 1, 2013 3:33 PM >> Subject: Re: Coniguring 301/302 redirects to track an fspath rename >> >> Bert Huijben wrote on Fri, Feb 01, 2013 at 21:28:10 +0100: >>> >>> >>> > -----Original Message----- >>> > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name] >>> > Sent: vrijdag 1 februari 2013 19:11 >>> > To: dev@subversion.apache.org >>> > Subject: Coniguring 301/302 redirects to track an fspath rename >>> > >>> > Does anyone have an example of how to configure a server to issue >>> > 301/302 redirects for an fspath that had been renamed? >>> > >>> > For example we have >>> > >>> >    <Location /repos/asf> >>> >    SVNPath ... >>> >    </Location> >>> > >>> > And we'd like to do: >>> > >>> >    # The project was renamed >>> >    Redirect /repos/asf/openejb https://svn.apache.org/repos/asf/tomee >>> > >>> > but we're hitting various problems: >>> > >>> > - The redirect kicks in for historical revisions (prior to the 'svn mv >>> >  ^/openejb ^/tomee' in r1432805) too, such as: >>> >  https://svn.apache.org/repos/asf/openejb?p=1400000 >>> > >>> > - A similar configuration failed to kick in during update/checkout of >>> >  working copy checked out from (a pre-rename revision of) ^/openejb: >>> >  the initial request got matched and redirected, but a subsequent >>> >  request to /repos/asf/!svn/.../openejb failed to match. >>> > >>> > Ideally we'd like to issue a 301 redirect for requests to /openejb that >>> > concern r1432805 or later, but leave requests concerning r1432804 or >>> > earlier untouched. >>> > >>> > (or maybe what we *really* want is a repos-side symlink... but we're >>> > running 1.7, not 1.9, and we'll appreciate solutions that work within >>> > that limitation :)) >>> >>> We currently only support redirects above the repository level. >>> >>> Redirections inside would be a completely different feature. >>> >> >> OK... :( >> >>> Why not just leave a top level folder with some readme? >>> >> >> Every time a podling graduates from the incubator, we do a rename: >>  svn mv ^/incubator/flex ^/flex >> >> If we can return 301 whenever somebody does 'svn up' in a wc of >> ^/incubator/flex, we'll save many users (2-4 projects every month) >> having to learn about 'svn relocate'. >> >>> I think you should be able to redirect the normal webbrowser GETs though, >>> as >>> I don't think we use those urls from our ra layers. (Or did we start using >>> them for HEAD requests in HTTPv2?) >>> >> >> 'svn ls $URL@peg' was affected by the redirects I had. >> >>>    Bert >>> >> >> Thanks, >> >> Daniel >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > >
Received on 2013-02-05 05:04:22 CET