Greg Stein wrote on Sat, Feb 02, 2013 at 02:15:43 -0500: > 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 client 301 handling happens in svn_ra_open4(), via the "const char **corrected_URL' parameter. svn_ra_open4() doesn't use REPORT, so it can't trigger the libsvn_client-level "Use the new URL" behaviour --- unless svn_ra_* grows a "Hey, I've belatedly corrected your URL; <here> is the new one" callback. > 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 > > > > > > > > > > > > > >
