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