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...@daniel.shahaf.name> > To: Joe Schaefer <joe_schae...@yahoo.com> > Cc: Greg Stein <gst...@gmail.com>; "dev@subversion.apache.org" > <dev@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...@daniel.shahaf.name> >> >To: Joe Schaefer <joe_schae...@yahoo.com> >> >Cc: Greg Stein <gst...@gmail.com>; > "dev@subversion.apache.org" <dev@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. >
