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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
