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