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 >> >> >> >> >>
