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

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-02 07:23:54 CET