In any case Daniel, what this boils down to is that we
need some way of distinguishing OPTIONS requests from svn
update that want HEAD, from operations that want something
older, in which case we probably shouldn't interfere with
the request. Having a specific revision number on the OPTIONS
request works but isn't actually essential to our use case.
Just try to keep in mind here that my role in this is to try
and help *you* Daniel- my original position when youfirst
mentioned this idea to me was similar to Ben's- that it
is unwise to introduce http redirects into an svn server's
url space.
----- Original Message -----
> From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
> To: Joe Schaefer <joe_schaefer_at_yahoo.com>
> Cc: Greg Stein <gstein_at_gmail.com>; "dev_at_subversion.apache.org" <dev_at_subversion.apache.org>
> Sent: Monday, February 4, 2013 2:53 AM
> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
> Joe Schaefer wrote on Sun, Feb 03, 2013 at 13:40:11 -0800:
>> >________________________________
>> > From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
>> >To: Joe Schaefer <joe_schaefer_at_yahoo.com>
>> >Cc: Greg Stein <gstein_at_gmail.com>;
> "dev_at_subversion.apache.org" <dev_at_subversion.apache.org>
>> >Sent: Sunday, February 3, 2013 4:15 PM
>> >Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>> >
>> >I already told you Joe: go over existing callers of svn_ra_open4() and
>> >see what value each of them could provide as the ?p= argument.
>>
>>
>> Thanks for barking more orders at me- I'd prefer collaboration where
>
> I wasn't.
>
Received on 2013-02-04 13:20:19 CET