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_schaefer_at_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_at_1000000
> >
> > and
> >
> > svn ls foo
> >
> > as far as making redirects pegrev-aware.
> >
> >
> > ------------------------------
> > *From:* Greg Stein <gstein_at_gmail.com>
> > *To:* Joe Schaefer <joe_schaefer_at_yahoo.com>
> > *Cc:* dev_at_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" <gstein_at_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_schaefer_at_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_schaefer_at_yahoo.com>
> > *To:* 'Daniel Shahaf' <d.s_at_daniel.shahaf.name>; Bert Huijben <
> > bert_at_qqmail.nl>
> > *Cc:* "dev_at_subversion.apache.org" <dev_at_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.s_at_daniel.shahaf.name>
> > *To:* Bert Huijben <bert_at_qqmail.nl>
> > *Cc:* dev_at_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.s_at_daniel.shahaf.name]
> > > > Sent: vrijdag 1 februari 2013 19:11
> > > > To: dev_at_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_at_peg' was affected by the redirects I had.
> >
> > > Bert
> > >
> >
> > Thanks,
> >
> > Daniel
> >
> >
> >
> >
> >
> >
> >
Received on 2013-02-02 08:25:13 CET