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