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 07:53:42 CET