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