That revision can appear in at least three places: a Label header, in the URL path, or in the URL querystring. Might also appear in a REPORT body for certain operations (not for 'ls', but likely for 'update'). In some cases, the revision might also appear in an X-SVN-$forgot header that is used for generating diff response bodies.
Likely not an easy problem :-P (and I'm only talking about the standard client; not that blasphemous SvnKit codebase). Cheers, -g On Feb 2, 2013 2:07 AM, "Joe Schaefer" <joe_schae...@yahoo.com> wrote: > The (pegrev) revision is typically available on > the command-line: all I want is for svn to distinguish > between > > svn ls foo@1000000 > > and > > svn ls foo > > as far as making redirects pegrev-aware. > > > ------------------------------ > *From:* Greg Stein <gst...@gmail.com> > *To:* Joe Schaefer <joe_schae...@yahoo.com> > *Cc:* dev@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" <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 > > > > > > >
