subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: Coniguring 301/302 redirects to track an fspath rename
Date Tue, 05 Feb 2013 04:03:40 GMT
Thanks Greg, that clears things up for me.






>________________________________
> From: Greg Stein <gstein@gmail.com>
>To: Joe Schaefer <joe_schaefer@yahoo.com> 
>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> 
>Sent: Monday, February 4, 2013 10:57 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
> 
>Better handling of redirects was released in 1.7.0.
>
>See: http://subversion.tigris.org/issues/show_bug.cgi?id=2779 and the
>CHANGES file.
>
>The working copy is not relocated, however. Just the error report. The
>user needs to follow up with some action. Other clients (eg
>TortoiseSVN) could theoretically perform an auto relocation, but the
>cmdline client does not.
>
>Cheers,
>-g
>
>
>On Mon, Feb 4, 2013 at 10:41 PM, Joe Schaefer <joe_schaefer@yahoo.com> wrote:
>> Has Daniel been pulling my leg this whole time
>> about this automatic relocation feature?  I don't
>> see any mention of it on the website for the 1.7
>> docs and have tested through 1.7.3 without seeing
>> it work.
>>
>> If there's work here that needs doing on
>> the subversion side I apologize for all the noise
>> I've generated, I thought this was a feature you
>> were already supporting on some level and was anxious
>> to take advantage of it.
>>
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Monday, February 4, 2013 8:15 PM
>>
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> Ok folks, some butt ugly code I wrote is fishing
>> the source url out of the REPORT request body on
>> update requests.  If I checkout revision 1400000
>> of
>>
>> http://svn.apache.org/repos/asf/incubator/openmeetings/trunk/singlewebapp
>>
>> that works fine, but then when I try to run
>>
>> $ svn up
>>
>> on that working copy, I get the following error:
>>
>>   svn: E175011: Repository moved permanently to
>>   'https://svn.apache.org/repos/asf/openmeetings/trunk/singlewebapp';
>>   please relocate
>>
>> Honestly that's an improvement, but not what I'm looking
>> for here: I need a way for the client to autoswitch to the
>> new location, not merely prompt the user to do it manually.
>> This is with svn 1.7.0, maybe things have changed since then?
>>
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Monday, February 4, 2013 4:48 PM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> Damn, processing updates requires fishing little
>> details out of a REPORT request body.  This is getting
>> complicated...
>>
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Monday, February 4, 2013 3:57 PM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> Here's the new section for the additional PROPFIND
>> rewrite block:
>>
>> /* RewriteCond %{SUBREQ} =false
>> */
>> /* RewriteCond %{REQUEST_METHOD} =PROPFIND
>> */
>> /* RewriteCond %{REQUEST_URI}
>> /repos/asf/!svn/(?:bc|rvr)/(\d+)/incubator/(.+)*/
>> /* RewriteCond /repos/asf/%2?ckpath  -U
>> */
>> /* RewriteRule .* /repos/asf/%2 [L,R=301]
>> */
>>
>>
>> As I said it works for me with openmeetings checkouts
>> out of incubator (1.6 and 1.7 clients point me at the
>> new location).  I am leery tho about dorking with !svn
>> based urls but these !svn/bc/$revision and !svn/rvr/$revision
>> ones are nice candidates because of the embedded revision
>> and path information that leads me to think I'm not too
>> far off in guessing that without interception by my module
>> we'd just be serving up 404's for them when they are looking
>> in the incubator tree for graduated podling resources.
>>
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Monday, February 4, 2013 2:44 PM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> Mixed news- I hacked together PROPFIND support
>> for my module and it's doing the "right thing"
>> on checkouts with 1.6 and 1.7. NFI what else this
>> breaks, but if folks could beat on incubating repos
>> for a bit to see I'd appreciate it.
>>
>> Thanks!
>>
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Monday, February 4, 2013 1:46 PM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> Oh damn, sigh.  I'm completely wrong- subversion doesn't
>> serve a 404 on the OPTIONS request, even for a resource
>> that's not present in HEAD.  It serves a 200 response,
>> and only several PROPFIND's later do we actually serve
>> a showstopping 404 on a checkout for a non-existent resource.
>>
>> That complicates this situation significantly, sorry.
>> I don't see an immediate way to satisfy the ASF's use
>> case given the current svn support for redirects revolves
>> around the initial OPTIONS response not PROPFINDS.
>>
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Monday, February 4, 2013 1:30 PM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> Please correct me if I'm mistaken, but my impression
>> from looking at server logs is that there are certain
>> cases where a 404 response to an initial OPTIONS request
>> is a showstopper (like a checkout or update operation),
>> but other times the 404 response is not a problem (like
>> for operations involving pegrevs).  If we can identify
>> this distinction and flag it somehow in the initial request
>> so that in the first case we ask for a non-showstopper
>> response from the server if available, that's all I need
>> to support the ASF's use case in my module.  Providing
>> additional version info in the query string can refine
>> the server response my httpd module would provide, but
>> that aspect is not essential to service the ASF's needs.
>>
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Monday, February 4, 2013 12:26 PM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> How about a "prefer redirect" flag somewhere in
>> the OPTIONS request?  Anything to signal to the
>> server that the request wants something better
>> than a 404 response it possible.
>>
>>
>> ________________________________
>> From: Greg Stein <gstein@gmail.com>
>> To: Joe Schaefer <joe_schaefer@yahoo.com>
>> Cc: dev@subversion.apache.org
>> Sent: Monday, February 4, 2013 7:44 AM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> Yeah... I think the best we can do in the OPTIONS is to hint. It can't
>> really be more than a hint, since a connection can be used for N various
>> operations.
>> What might be more ideal is to respect redirects after that initial OPTIONS.
>> Then your module could just wait until it knows the right data.
>> It's not an easy problem. If we get a 301, then we should definitely rewrite
>> the working copy to use the new URL. But... is a 301 correct, if "old"
>> revisions still work? ....
>> Cheers,
>> -g
>> On Feb 3, 2013 2:33 PM, "Joe Schaefer" <joe_schaefer@yahoo.com> wrote:
>>
>> We don't actually need the subversion server
>> to do anything useful with the query string
>> on an OPTIONS request.  We just need it as
>> a hint for http server admins, combined with
>> a (global) configuration option to tell our
>> working copies to autoswitch when they see a
>> 301 on the initial OPTIONS response.
>>
>> Sorry if this is getting boring.  In no way is
>> it essential, but we have significant working copy
>> investments in incubating projects that are a pain
>> to manage administratively right now whenever a project
>> graduates.  Anything along these lines to cut down
>> on the human labor aspects would be most welcome.
>>
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Sunday, February 3, 2013 1:45 PM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> IOW the easiest way for us to support OPTIONS
>> requests with this module, which would require
>> no code changes to the module I wrote, is for the
>> initial OPTIONS request to hang a ?p=whatever
>> query string onto the request whenever it's dealing
>> with pegrevs.
>>
>>
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Sunday, February 3, 2013 1:04 PM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> A few urls to fetch to get the basic idea:
>>
>> http://svn.apache.org/repos/asf/incubator/openmeetings/trunk
>> (will redirect)
>>
>> http://svn.apache.org/repos/asf/incubator/openmeetings/trunk?p=1400000
>> (won't redirect)
>>
>>
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Sunday, February 3, 2013 12:15 PM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> The code is here if you are interested (dunno
>> if it's publicly accessible or not but I believe
>> so).
>>
>> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Sunday, February 3, 2013 12:10 PM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> I backed off with the idea of trying to coax
>> new behavior out of svn clients by munging OPTIONS
>> responses, but GET and HEAD are now doing
>> interesting things even with ?p= set.  For our
>> purposes someday it would be nice to just have
>> a graduating podling's checkouts all auto-switch
>> to the moved location.  Whether that's
>> accomplished by augmenting an OPTIONS request
>> with revision details or just using the existing
>> GET/HEAD support or some other method would be
>> just fine with me.
>>
>>
>> ________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>> To: Greg Stein <gstein@gmail.com>
>> Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
>> Sent: Saturday, February 2, 2013 2:07 AM
>> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> 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 <gstein@gmail.com>
>> To: Joe Schaefer <joe_schaefer@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" <gstein@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@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@yahoo.com>
>> To: 'Daniel Shahaf' <d.s@daniel.shahaf.name>; Bert Huijben <bert@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.s@daniel.shahaf.name>
>> To: Bert Huijben <bert@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.s@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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
Mime
View raw message