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_at_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_at_1000000
>
> and
>
> svn ls foo
>
>
> as far as making redirects pegrev-aware.
>
>
>
>
>
> >________________________________
> > From: Greg Stein <gstein_at_gmail.com>
> >To: Joe Schaefer <joe_schaefer_at_yahoo.com>
> >Cc: dev_at_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" <gstein_at_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_schaefer_at_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_schaefer_at_yahoo.com>
> >>>>To: 'Daniel Shahaf' <d.s_at_daniel.shahaf.name>; Bert Huijben <bert_at_qqmail.nl>
> >>>>Cc: "dev_at_subversion.apache.org" <dev_at_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_at_daniel.shahaf.name>
> >>>>>To: Bert Huijben <bert_at_qqmail.nl>
> >>>>>Cc: dev_at_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_at_daniel.shahaf.name]
> >>>>>> > Sent: vrijdag 1 februari 2013 19:11
> >>>>>> > To: dev_at_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_at_peg' was affected by the redirects I had.
> >>>>>
> >>>>>> Bert
> >>>>>>
> >>>>>
> >>>>>Thanks,
> >>>>>
> >>>>>Daniel
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >
> >
Received on 2013-02-02 08:21:35 CET