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 <gst...@gmail.com> >To: Joe Schaefer <joe_schae...@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_schae...@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_schae...@yahoo.com> >>>To: Greg Stein <gst...@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_schae...@yahoo.com> >>>>To: Greg Stein <gst...@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_schae...@yahoo.com> >>>>>To: Greg Stein <gst...@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_schae...@yahoo.com> >>>>>>To: Greg Stein <gst...@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_schae...@yahoo.com> >>>>>>>To: Greg Stein <gst...@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 <gst...@gmail.com> >>>>>>>>To: Joe Schaefer <joe_schae...@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" <gst...@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_schae...@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_schae...@yahoo.com> >>>>>>>>>>>To: 'Daniel Shahaf' <d...@daniel.shahaf.name>; Bert Huijben >>>>>>>>>>><b...@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...@daniel.shahaf.name> >>>>>>>>>>>>To: Bert Huijben <b...@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...@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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> > >
