The redirects logic happens in svn_ra_open4(), so you'll want to have it grow an optional svn_revnum_t parameter (that can take the values NULL or HEAD or an integer), which svn_ra_serf__open() would then tack on to the request for your custom module to intercept.
'svn checkout' won't populate the new optional parameter, but 'svn ls foo@peg' and update/checkout could conceivably populate it. I'm just not sure how far the revnum value is from the svn_ra_open4 call. Joe Schaefer wrote on Fri, Feb 01, 2013 at 23:07:43 -0800: > 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 > >>>>> > >>>>> > >>>>> > >>>> > >>>> > > > >
