You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2013/02/01 19:11:22 UTC
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 :))
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
Then frankly we didn't address the ticket
properly because that Redirect Jon Stevens
mentioned was within the same svn repository,
so a relocate operation was always the "wrong"
solution to begin with.
>________________________________
> From: C. Michael Pilato <cm...@collab.net>
>To: Greg Stein <gs...@gmail.com>
>Cc: Joe Schaefer <jo...@yahoo.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>Sent: Tuesday, February 5, 2013 10:07 AM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>On 02/04/2013 10:57 PM, Greg Stein wrote:
>> 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
>
>That's not ... entirely ... true. In 1.7, I actually did teach Subversion's
>update functionality to automatically relocate the working copy if the
>server sends a permanent redirect during whatever requests comprise the
>svn_ra_open() handling.
>
>The problem I see with all of the chatter in this thread is that 'relocate'
>is precisely the *wrong* action for the user to take. If the repository
>directory has simply been moved to some other place in the same repository,
>this calls for a regular 'svn switch'. Relocation is a metadata-only
>transformation within the working copy, which tweaks the repos_root_url and
>repos_relpath as a way of dealing with the situation where a whole
>repository has been moved to/exposed at a different URL. You need something
>here that operates *within the same repository* and which traverses not just
>space (URLs) but time also (revisions). That's 'svn switch'. We have no
>client-side automated support for 'svn switch'ing to a new location.
>
>So, I hate to be the bearer of bad tidings, but this entire exercise is a
>giant waste of time and energy.
>
>--
>C. Michael Pilato <cm...@collab.net>
>CollabNet <> www.collab.net <> Enterprise Cloud Development
>
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
FWIW I don't consider YOUR email counterproductive.
Let's stop discussing the incivility and move on
to more productive discussions, like how svn.apache.org
behaves right now towards incubating projects.
If compelling evidence presents itself that my module
breaks essential features of svn, I'll be the first
one to remove it from service. But really, I can't
be the only person on this list interested in interrogating
the server before offering an opinion- that makes for
lots of useless banter that doesn't move the ball
forward IMO.
>________________________________
> From: Johan Corveleyn <jc...@gmail.com>
>To: Joe Schaefer <jo...@yahoo.com>
>Cc: Branko Čibej <br...@wandisco.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>Sent: Tuesday, February 5, 2013 4:50 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>On Tue, Feb 5, 2013 at 10:21 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>> Calling a coded solution a "giant waste
>> of time and energy" is highly uncivilized
>> at the ASF, please let's not paper over that.
>
>Oh come on. You're overreacting.
>
>The fact that you started this discussion (and perhaps your written
>code helped drive it a bit) is at least not a waste of time. But you
>need to also *allow* discussion, otherwise this is all indeed an
>exercise in futility.
>
>In general though I don't think it's a good idea to spend the effort
>of writing some code before you've bounced off your idea with the
>community. You might end up wasting your time and energy for something
>that maybe isn't such a good idea after all (or something for which
>you cannot find consensus in the community, which means you won't get
>it in there).
>
>> The "solution" I have in mind for update and
>> checkout support is already live on svn.apache.org,
>> all I need is some sensible optional support from
>> the client. Why this involves knuckle-dragging is
>> beyond me. Please do me a favor and test out the
>> code I wrote before insulting me further- thx.
>
>What knuckly-dragging? What "insulting me further"? If you consider my
>mail insulting, djeez ... I don't know what to say. Pffff, go ahead
>and scare everyone away from a meaningful discussion if you like that.
>
>--
>Johan
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Feb 5, 2013 at 10:21 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> Calling a coded solution a "giant waste
> of time and energy" is highly uncivilized
> at the ASF, please let's not paper over that.
Oh come on. You're overreacting.
The fact that you started this discussion (and perhaps your written
code helped drive it a bit) is at least not a waste of time. But you
need to also *allow* discussion, otherwise this is all indeed an
exercise in futility.
In general though I don't think it's a good idea to spend the effort
of writing some code before you've bounced off your idea with the
community. You might end up wasting your time and energy for something
that maybe isn't such a good idea after all (or something for which
you cannot find consensus in the community, which means you won't get
it in there).
> The "solution" I have in mind for update and
> checkout support is already live on svn.apache.org,
> all I need is some sensible optional support from
> the client. Why this involves knuckle-dragging is
> beyond me. Please do me a favor and test out the
> code I wrote before insulting me further- thx.
What knuckly-dragging? What "insulting me further"? If you consider my
mail insulting, djeez ... I don't know what to say. Pffff, go ahead
and scare everyone away from a meaningful discussion if you like that.
--
Johan
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
Calling a coded solution a "giant waste
of time and energy" is highly uncivilized
at the ASF, please let's not paper over that.
The "solution" I have in mind for update and
checkout support is already live on svn.apache.org,
all I need is some sensible optional support from
the client. Why this involves knuckle-dragging is
beyond me. Please do me a favor and test out the
code I wrote before insulting me further- thx.
>________________________________
> From: Johan Corveleyn <jc...@gmail.com>
>To: Joe Schaefer <jo...@yahoo.com>
>Cc: Branko Čibej <br...@wandisco.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>Sent: Tuesday, February 5, 2013 2:32 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>On Tue, Feb 5, 2013 at 8:04 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>> It was civil until CMike got on his
>> high horse- you need to police yourselves
>> a bit better before you start accusing
>> outsiders of misbehavior- that's how civility
>> starts degrading in a project.
>
>Woah, there must be some different wavelengths in this conversation.
>
>I didn't see any high horse in CMike's response. I found his response
>exactly to the point (pointing out that 'relocate' is the wrong action
>here, and that there is a need for a 'switch' (or for 'update'
>following moves of the working copy root, which is another way of
>putting it), and that's not a feature we currently have).
>
>Or maybe you're referring to his mention of "chatter in this thread"
>(which was, frankly, quite true, because of the sheer amount of posts
>-- but I wouldn't take that as offensive), or of "a giant waste of
>time and energy" (which sadly seems to be also true, however bad that
>sounds). Nothing uncivil AFAICS.
>
>> The fact is that a robust solution involves
>> coding this up as part of the generic exception
>> handling mechanics for whatever svn ops can deal
>> with 301s. What's currently in 1.7 that we're
>> pretending automates the redirect problem is inadequate
>> for any serious svn http server administrator trying
>> to track moves. This is not an idle question-
>> Daniel actually tried putting a Redirect block
>> in for the openejb -> tomee rename and all it wound
>> up doing is destroying any attempts to crawl
>> the project's pre-move history. We had to back
>> out the change just to let our git-svn mirror
>> pick up the new tomee location and DTRT with the
>> history.
>
>Sure, it's a genuine feature request (though you're the first one
>bringing this up AFAIK), but it's simply not a feature of svn at the
>moment. Please allow for some discussion (which includes pointing out
>that this might not be as simple as you think it is), before accusing
>some of as of being dicks.
>
>And, now that we arrived at the conclusion that this has nothing to do
>with the 1.7 feature of "automatic relocate on redirect": no this is
>not a feature we ostensibly support, this is something quite
>different.
>
>--
>Johan
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Feb 5, 2013 at 8:04 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> It was civil until CMike got on his
> high horse- you need to police yourselves
> a bit better before you start accusing
> outsiders of misbehavior- that's how civility
> starts degrading in a project.
Woah, there must be some different wavelengths in this conversation.
I didn't see any high horse in CMike's response. I found his response
exactly to the point (pointing out that 'relocate' is the wrong action
here, and that there is a need for a 'switch' (or for 'update'
following moves of the working copy root, which is another way of
putting it), and that's not a feature we currently have).
Or maybe you're referring to his mention of "chatter in this thread"
(which was, frankly, quite true, because of the sheer amount of posts
-- but I wouldn't take that as offensive), or of "a giant waste of
time and energy" (which sadly seems to be also true, however bad that
sounds). Nothing uncivil AFAICS.
> The fact is that a robust solution involves
> coding this up as part of the generic exception
> handling mechanics for whatever svn ops can deal
> with 301s. What's currently in 1.7 that we're
> pretending automates the redirect problem is inadequate
> for any serious svn http server administrator trying
> to track moves. This is not an idle question-
> Daniel actually tried putting a Redirect block
> in for the openejb -> tomee rename and all it wound
> up doing is destroying any attempts to crawl
> the project's pre-move history. We had to back
> out the change just to let our git-svn mirror
> pick up the new tomee location and DTRT with the
> history.
Sure, it's a genuine feature request (though you're the first one
bringing this up AFAIK), but it's simply not a feature of svn at the
moment. Please allow for some discussion (which includes pointing out
that this might not be as simple as you think it is), before accusing
some of as of being dicks.
And, now that we arrived at the conclusion that this has nothing to do
with the 1.7 feature of "automatic relocate on redirect": no this is
not a feature we ostensibly support, this is something quite
different.
--
Johan
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/06/2013 02:08 PM, Joe Schaefer wrote:
> However, if we svn devs ever release a client that allows an admin to
> bless an svn client to intelligently follow a 301 on a working copy
> update operation, all of Daniel's scripting efforts can be eradicated
> when it comes to the CMS- the CMS would no longer require ANY
> administrative changes to support podling graduations, it would just
> continue to work right out of the box.
I'd like to suggest that the correct long-term way to deal with this is not
with a 301 at all, but with mod_dav_svn being smart enough to say (in
response to "I want to update my working copy of /some/path") simply, "Sure,
here's your update -- but please note that it's being pulled from
/another/path now." In other words, there shouldn't be any administrator
action required here.
The way I've long envisioned this working is that the server, upon being
asked to update a working copy based on some repository location which
doesn't exist in REVISION-TO-WHICH-ITS-UPDATING, can trace node ancestry to
find one or more suitable alternate locations the client might try, and
presents those to the client as options. If there's more than one (due to
the original source being copied multiple times to new locations), the user
gets a choice. If there's only one option, maybe the user is queried or
maybe stuff moves on automatically -- I dunno. One downside of all of this
is that the server today is simply too stupid to even make such a
recommendation.
Also, the more I think about it, the less I'm convinced that the client's
current 'svn switch' mechanics are sufficient for this. An 'svn update' of
a working copy that has switched subtrees will maintain those switches,
while an 'svn switch' of such a working copy will effectively un-switch
those subtrees as part of switching their parent tree. I'll grant that this
particular detail is disinteresting to the CMS situation, but it is
interesting in the general sense. (Easy solution: when automatically
transforming an 'svn update' to an 'svn switch', the client queries the
working copy for switched subtrees, and, if it finds some, errors out with a
message saying that automation isn't an option and the working copy needs to
be manually switched.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
And again to explain a typical use case that
would make infra's life easier- let me tell
you briefly about CMS sites. The Apache CMS
is basically a CI service for websites, with
a simple webgui that wraps common svn client
commands on serve-side checkouts of a project's
website sources in svn. There are several
associated checkouts sitting in a zfs filesystem
associated with the webgui, and when a project
graduates right now those working copies and
the associated zfs filesystem all need to be
destroyed and repopulated based on the new location
of the site's sources in svn. Ditto for the
buildbot CI checkout of the site. While we
could go in an do some svn switch surgery ourselves,
it is easier for administrative purposes to nuke
the entire zfs filesystem and buildbot wc and start
over.
Needless to say this is a cumbersome process
that people like Daniel are trying to simplify
with some generic admin-use scripting. However, if we
svn devs ever release a client that allows an admin
to bless an svn client to intelligently follow a
301 on a working copy update operation, all of
Daniel's scripting efforts can be eradicated when
it comes to the CMS- the CMS would no longer require
ANY administrative changes to support podling
graduations, it would just continue to work right
out of the box.
>________________________________
> From: Joe Schaefer <jo...@yahoo.com>
>To: C. Michael Pilato <cm...@collab.net>
>Cc: Branko Čibej <br...@wandisco.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>Sent: Wednesday, February 6, 2013 1:34 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>
>I'd like to try to make the case that this kind
>of support on the server side is actually undesirable
>to bake in to mod_dav_svn, because the typical
>copy + delete semantics of a move are entirely
>satisfactory for moves within the confines of
>someone's working copy. It's only when we start
>moving around entire projects (or even entire
>repositories) that having some redirect support
>becomes useful to http admins.
>
>
>
>
>
>
>>________________________________
>> From: Joe Schaefer <jo...@yahoo.com>
>>To: C. Michael Pilato <cm...@collab.net>
>>Cc: Branko Čibej <br...@wandisco.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>>Sent: Tuesday, February 5, 2013 5:23 PM
>>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>>
>>Look, I wasn't even interested in this issue
>>until Daniel mentioned on IRC that some automated
>>behavior was new in 1.7 that we might be able to use.
>>That explains my drive towards an answer- one that
>>I now understand won't work with existing clients.
>>That is fine with me, and I'm happy that now that
>>we're all on the same page. Groovy.
>>
>>I do get different behavior out of 1.7 clients, and
>>it may be that my current solution really only "works"
>>(in terms of generating a proper err msg) for 1.7 + neon.
>>Technically the Location header you should have gotten was
>>meant to include trunk- I don't know at this point why you
>>got the parent url other than my REPORT processing in the
>>module is very
naive.
>>
>>
>>
>>
>>
>>
>>
>>
>>>________________________________
>>> From: C. Michael Pilato <cm...@collab.net>
>>>To: Joe Schaefer <jo...@yahoo.com>
>>>Cc: Branko Čibej <br...@wandisco.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>>>Sent: Tuesday, February 5, 2013 5:16 PM
>>>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>>
>>>On 02/05/2013 04:56 PM, Joe Schaefer wrote:
>>>> Telling me this is a dead-end task without explanation does not exactly
>>>> instill me with confidence in your opinion- I'd like to see you explain
>>>> why the software I wrote and am now using in production cannot possibly
>>>> work as intended. Again do me a favor and test it if you cannot figure
>>>> out how it works from source:
>>>
>>>So, I think the disconnect stems from my (apparent) misunderstanding that
>>>you were seeking an automated solution that was available *today* to this
>>>very incubator graduate. Something that would allow the users of that
>>>codebase to effectively not even really notice that the project has been
>>>moved elsewhere in the repository. Sorry for not noticing that the thread
>>>had shifted into a consideration of some as-yet-uncharted future.
>>>
>>>> % svn co
http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000
>>>> % cd trunk
>>>> % svn up
>>>>
>>>> Post the output if you do not understand what our
>>>> server is trying to convey when you issue those commands.
>>>
>>>Well, I see this (using an 1.8.0-dev Subversion client):
>>>
>>>{{{
>>>$ svn co http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000
>>>A trunk/singlewebapp
>>>A trunk/singlewebapp/test
>>>A trunk/singlewebapp/test/filename1.wml
>>>A trunk/debian_package/etc/init.d
>>>A trunk/debian_package/etc/init.d/ooomeetings
>>>A trunk/debian_package/etc/init.d/red5-openmeetings
>>>Checked out revision 1400000.
>>>$ cd trunk/
>>>$ svn up
>>>Updating '.':
>>>subversion/svn/update-cmd.c:175:
(apr_err=175011)
>>>subversion/libsvn_client/update.c:625: (apr_err=175011)
>>>subversion/libsvn_client/update.c:565: (apr_err=175011)
>>>subversion/libsvn_client/update.c:381: (apr_err=175011)
>>>subversion/libsvn_client/iprops.c:273: (apr_err=175011)
>>>subversion/libsvn_client/iprops.c:217: (apr_err=175011)
>>>subversion/libsvn_ra/ra_loader.c:1323: (apr_err=175011)
>>>subversion/libsvn_ra/compat.c:914: (apr_err=175011)
>>>subversion/libsvn_ra_serf/serf.c:1081: (apr_err=175011)
>>>subversion/libsvn_ra_serf/property.c:694: (apr_err=175011)
>>>subversion/libsvn_ra_serf/property.c:670: (apr_err=175011)
>>>subversion/libsvn_ra_serf/util.c:2376: (apr_err=175011)
>>>svn: E175011: Repository moved permanently to '(null)'; please relocate
>>>$
>>>}}}
>>>
>>>But I suspect that's not precisely what you see.
>>>
>>>From this I gather the server has issued a Redirect. Indeed, from a
>>>wireshark trace, I see the Redirect was of the 301 variety and contains
this
>>>header:
>>>
>>> Location: http://svn.apache.org/repos/asf/openmeetings
>>>
>>>So, looks good so far. It seems the client has a problem properly parsing
>>>the header -- something we need to fix if that hasn't been done already.
>>>
>>>> Again the source code for my module is at
>>>> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path
>>>>
>>>> As I said earlier, the reason we are bandying about relocate is because
>>>> that's how you coded up the solution to Jon's ticket. I again don't see
>>>> the difficulty in interrogating the target server's UUID on a 301 and
>>>> determining whether or not a relocate is warranted over a simple svn
>>>> switch- please enlighten me on the difficulties.
>>>
>>>Oh, I'm not saying that it can't be done using some
future version
of
>>>Subversion that chooses switch or relocate as needed. (See
>>>"misunderstanding" above.)
>>>
>>>> Let's move forward with an honest technical discussion based on actual
>>>> research on existing solution instead of arguing from authority and
>>>> continuing to discuss social failings instead of technical ones. Thx in
>>>> advance.
>>>
>>>Agreed.
>>>
>>>--
>>>C. Michael Pilato <cm...@collab.net>
>>>CollabNet <> www.collab.net <> Enterprise Cloud Development
>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
I'd like to try to make the case that this kind
of support on the server side is actually undesirable
to bake in to mod_dav_svn, because the typical
copy + delete semantics of a move are entirely
satisfactory for moves within the confines of
someone's working copy. It's only when we start
moving around entire projects (or even entire
repositories) that having some redirect support
becomes useful to http admins.
>________________________________
> From: Joe Schaefer <jo...@yahoo.com>
>To: C. Michael Pilato <cm...@collab.net>
>Cc: Branko Čibej <br...@wandisco.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>Sent: Tuesday, February 5, 2013 5:23 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>
>Look, I wasn't even interested in this issue
>until Daniel mentioned on IRC that some automated
>behavior was new in 1.7 that we might be able to use.
>That explains my drive towards an answer- one that
>I now understand won't work with existing clients.
>That is fine with me, and I'm happy that now that
>we're all on the same page. Groovy.
>
>I do get different behavior out of 1.7 clients, and
>it may be that my current solution really only "works"
>(in terms of generating a proper err msg) for 1.7 + neon.
>Technically the Location header you should have gotten was
>meant to include trunk- I don't know at this point why you
>got the parent url other than my REPORT processing in the
>module is very naive.
>
>
>
>
>
>
>
>
>>________________________________
>> From: C. Michael Pilato <cm...@collab.net>
>>To: Joe Schaefer <jo...@yahoo.com>
>>Cc: Branko Čibej <br...@wandisco.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>>Sent: Tuesday, February 5, 2013 5:16 PM
>>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>>On 02/05/2013 04:56 PM, Joe Schaefer wrote:
>>> Telling me this is a dead-end task without explanation does not exactly
>>> instill me with confidence in your opinion- I'd like to see you explain
>>> why the software I wrote and am now using in production cannot possibly
>>> work as intended. Again do me a favor and test it if you cannot figure
>>> out how it works from source:
>>
>>So, I think the disconnect stems from my (apparent) misunderstanding that
>>you were seeking an automated solution that was available *today* to this
>>very incubator graduate. Something that would allow the users of that
>>codebase to effectively not even really notice that the project has been
>>moved elsewhere in the repository. Sorry for not noticing that the thread
>>had shifted into a consideration of some as-yet-uncharted future.
>>
>>> % svn co
http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000
>>> % cd trunk
>>> % svn up
>>>
>>> Post the output if you do not understand what our
>>> server is trying to convey when you issue those commands.
>>
>>Well, I see this (using an 1.8.0-dev Subversion client):
>>
>>{{{
>>$ svn co http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000
>>A trunk/singlewebapp
>>A trunk/singlewebapp/test
>>A trunk/singlewebapp/test/filename1.wml
>>A trunk/debian_package/etc/init.d
>>A trunk/debian_package/etc/init.d/ooomeetings
>>A trunk/debian_package/etc/init.d/red5-openmeetings
>>Checked out revision 1400000.
>>$ cd trunk/
>>$ svn up
>>Updating '.':
>>subversion/svn/update-cmd.c:175:
(apr_err=175011)
>>subversion/libsvn_client/update.c:625: (apr_err=175011)
>>subversion/libsvn_client/update.c:565: (apr_err=175011)
>>subversion/libsvn_client/update.c:381: (apr_err=175011)
>>subversion/libsvn_client/iprops.c:273: (apr_err=175011)
>>subversion/libsvn_client/iprops.c:217: (apr_err=175011)
>>subversion/libsvn_ra/ra_loader.c:1323: (apr_err=175011)
>>subversion/libsvn_ra/compat.c:914: (apr_err=175011)
>>subversion/libsvn_ra_serf/serf.c:1081: (apr_err=175011)
>>subversion/libsvn_ra_serf/property.c:694: (apr_err=175011)
>>subversion/libsvn_ra_serf/property.c:670: (apr_err=175011)
>>subversion/libsvn_ra_serf/util.c:2376: (apr_err=175011)
>>svn: E175011: Repository moved permanently to '(null)'; please relocate
>>$
>>}}}
>>
>>But I suspect that's not precisely what you see.
>>
>>From this I gather the server has issued a Redirect. Indeed, from a
>>wireshark trace, I see the Redirect was of the 301 variety and contains
this
>>header:
>>
>> Location: http://svn.apache.org/repos/asf/openmeetings
>>
>>So, looks good so far. It seems the client has a problem properly parsing
>>the header -- something we need to fix if that hasn't been done already.
>>
>>> Again the source code for my module is at
>>> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path
>>>
>>> As I said earlier, the reason we are bandying about relocate is because
>>> that's how you coded up the solution to Jon's ticket. I again don't see
>>> the difficulty in interrogating the target server's UUID on a 301 and
>>> determining whether or not a relocate is warranted over a simple svn
>>> switch- please enlighten me on the difficulties.
>>
>>Oh, I'm not saying that it can't be done using some future version
of
>>Subversion that chooses switch or relocate as needed. (See
>>"misunderstanding" above.)
>>
>>> Let's move forward with an honest technical discussion based on actual
>>> research on existing solution instead of arguing from authority and
>>> continuing to discuss social failings instead of technical ones. Thx in
>>> advance.
>>
>>Agreed.
>>
>>--
>>C. Michael Pilato <cm...@collab.net>
>>CollabNet <> www.collab.net <> Enterprise Cloud Development
>>
>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
Look, I wasn't even interested in this issue
until Daniel mentioned on IRC that some automated
behavior was new in 1.7 that we might be able to use.
That explains my drive towards an answer- one that
I now understand won't work with existing clients.
That is fine with me, and I'm happy that now that
we're all on the same page. Groovy.
I do get different behavior out of 1.7 clients, and
it may be that my current solution really only "works"
(in terms of generating a proper err msg) for 1.7 + neon.
Technically the Location header you should have gotten was
meant to include trunk- I don't know at this point why you
got the parent url other than my REPORT processing in the
module is very naive.
>________________________________
> From: C. Michael Pilato <cm...@collab.net>
>To: Joe Schaefer <jo...@yahoo.com>
>Cc: Branko Čibej <br...@wandisco.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>Sent: Tuesday, February 5, 2013 5:16 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>On 02/05/2013 04:56 PM, Joe Schaefer wrote:
>> Telling me this is a dead-end task without explanation does not exactly
>> instill me with confidence in your opinion- I'd like to see you explain
>> why the software I wrote and am now using in production cannot possibly
>> work as intended. Again do me a favor and test it if you cannot figure
>> out how it works from source:
>
>So, I think the disconnect stems from my (apparent) misunderstanding that
>you were seeking an automated solution that was available *today* to this
>very incubator graduate. Something that would allow the users of that
>codebase to effectively not even really notice that the project has been
>moved elsewhere in the repository. Sorry for not noticing that the thread
>had shifted into a consideration of some as-yet-uncharted future.
>
>> % svn co http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000
>> % cd trunk
>> % svn up
>>
>> Post the output if you do not understand what our
>> server is trying to convey when you issue those commands.
>
>Well, I see this (using an 1.8.0-dev Subversion client):
>
>{{{
>$ svn co http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000
>A trunk/singlewebapp
>A trunk/singlewebapp/test
>A trunk/singlewebapp/test/filename1.wml
>A trunk/debian_package/etc/init.d
>A trunk/debian_package/etc/init.d/ooomeetings
>A trunk/debian_package/etc/init.d/red5-openmeetings
>Checked out revision 1400000.
>$ cd trunk/
>$ svn up
>Updating '.':
>subversion/svn/update-cmd.c:175: (apr_err=175011)
>subversion/libsvn_client/update.c:625: (apr_err=175011)
>subversion/libsvn_client/update.c:565: (apr_err=175011)
>subversion/libsvn_client/update.c:381: (apr_err=175011)
>subversion/libsvn_client/iprops.c:273: (apr_err=175011)
>subversion/libsvn_client/iprops.c:217: (apr_err=175011)
>subversion/libsvn_ra/ra_loader.c:1323: (apr_err=175011)
>subversion/libsvn_ra/compat.c:914: (apr_err=175011)
>subversion/libsvn_ra_serf/serf.c:1081: (apr_err=175011)
>subversion/libsvn_ra_serf/property.c:694: (apr_err=175011)
>subversion/libsvn_ra_serf/property.c:670: (apr_err=175011)
>subversion/libsvn_ra_serf/util.c:2376: (apr_err=175011)
>svn: E175011: Repository moved permanently to '(null)'; please relocate
>$
>}}}
>
>But I suspect that's not precisely what you see.
>
>From this I gather the server has issued a Redirect. Indeed, from a
>wireshark trace, I see the Redirect was of the 301 variety and contains this
>header:
>
> Location: http://svn.apache.org/repos/asf/openmeetings
>
>So, looks good so far. It seems the client has a problem properly parsing
>the header -- something we need to fix if that hasn't been done already.
>
>> Again the source code for my module is at
>> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path
>>
>> As I said earlier, the reason we are bandying about relocate is because
>> that's how you coded up the solution to Jon's ticket. I again don't see
>> the difficulty in interrogating the target server's UUID on a 301 and
>> determining whether or not a relocate is warranted over a simple svn
>> switch- please enlighten me on the difficulties.
>
>Oh, I'm not saying that it can't be done using some future version of
>Subversion that chooses switch or relocate as needed. (See
>"misunderstanding" above.)
>
>> Let's move forward with an honest technical discussion based on actual
>> research on existing solution instead of arguing from authority and
>> continuing to discuss social failings instead of technical ones. Thx in
>> advance.
>
>Agreed.
>
>--
>C. Michael Pilato <cm...@collab.net>
>CollabNet <> www.collab.net <> Enterprise Cloud Development
>
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Greg Stein <gs...@gmail.com>.
Cool. Looks good, along with my change last year.
On Feb 7, 2013 9:54 AM, "C. Michael Pilato" <cm...@collab.net> wrote:
> I committed this patch plus the fixes for the other problem I mentioned in
> r1443578, hopefully without breaking the workaround that Greg put into
> place
> in r1351138 for sloppy code.google.com response generation.
>
>
> On 02/05/2013 05:44 PM, C. Michael Pilato wrote:
> > On 02/05/2013 05:26 PM, Bert Huijben wrote:
> >> Looking at this stack, this error originates in the iprops fetch that
> was
> >> added before the actual update for 1.8.
> >
> > Here's the immediate fix for the NULL location:
> >
> > {{{
> > Index: subversion/libsvn_ra_serf/property.c
> > ===================================================================
> > --- subversion/libsvn_ra_serf/property.c (revision 1442766)
> > +++ subversion/libsvn_ra_serf/property.c (working copy)
> > @@ -637,7 +637,7 @@
> >
> > err2 = svn_ra_serf__error_on_status(handler->sline.code,
> > handler->path,
> > - NULL);
> > + handler->location);
> > if (err2)
> > {
> > svn_error_clear(err);
> > }}}
> >
> > I haven't time to give a full test run right now -- heading out the door
> for
> > a meeting.
> >
> > But there's another problem here anyway, which is that
> > response_get_location() in libsvn_ra_serf/util.c is only return the path
> > portion of the URL provided by the server. Not sure precisely when that
> > started happening -- r1351138 seems key here -- but either way, we
> > absolutely need the full (canonicalized-for-Subversion-use) URL here to
> > continue properly handling redirects which point to a different server.
> >
>
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Enterprise Cloud Development
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by "C. Michael Pilato" <cm...@collab.net>.
I committed this patch plus the fixes for the other problem I mentioned in
r1443578, hopefully without breaking the workaround that Greg put into place
in r1351138 for sloppy code.google.com response generation.
On 02/05/2013 05:44 PM, C. Michael Pilato wrote:
> On 02/05/2013 05:26 PM, Bert Huijben wrote:
>> Looking at this stack, this error originates in the iprops fetch that was
>> added before the actual update for 1.8.
>
> Here's the immediate fix for the NULL location:
>
> {{{
> Index: subversion/libsvn_ra_serf/property.c
> ===================================================================
> --- subversion/libsvn_ra_serf/property.c (revision 1442766)
> +++ subversion/libsvn_ra_serf/property.c (working copy)
> @@ -637,7 +637,7 @@
>
> err2 = svn_ra_serf__error_on_status(handler->sline.code,
> handler->path,
> - NULL);
> + handler->location);
> if (err2)
> {
> svn_error_clear(err);
> }}}
>
> I haven't time to give a full test run right now -- heading out the door for
> a meeting.
>
> But there's another problem here anyway, which is that
> response_get_location() in libsvn_ra_serf/util.c is only return the path
> portion of the URL provided by the server. Not sure precisely when that
> started happening -- r1351138 seems key here -- but either way, we
> absolutely need the full (canonicalized-for-Subversion-use) URL here to
> continue properly handling redirects which point to a different server.
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/05/2013 05:26 PM, Bert Huijben wrote:
> Looking at this stack, this error originates in the iprops fetch that was
> added before the actual update for 1.8.
Here's the immediate fix for the NULL location:
{{{
Index: subversion/libsvn_ra_serf/property.c
===================================================================
--- subversion/libsvn_ra_serf/property.c (revision 1442766)
+++ subversion/libsvn_ra_serf/property.c (working copy)
@@ -637,7 +637,7 @@
err2 = svn_ra_serf__error_on_status(handler->sline.code,
handler->path,
- NULL);
+ handler->location);
if (err2)
{
svn_error_clear(err);
}}}
I haven't time to give a full test run right now -- heading out the door for
a meeting.
But there's another problem here anyway, which is that
response_get_location() in libsvn_ra_serf/util.c is only return the path
portion of the URL provided by the server. Not sure precisely when that
started happening -- r1351138 seems key here -- but either way, we
absolutely need the full (canonicalized-for-Subversion-use) URL here to
continue properly handling redirects which point to a different server.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
RE: Coniguring 301/302 redirects to track an fspath rename
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: dinsdag 5 februari 2013 23:16
> To: Joe Schaefer
> Cc: Branko Čibej; dev@subversion.apache.org
> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
> On 02/05/2013 04:56 PM, Joe Schaefer wrote:
> > Telling me this is a dead-end task without explanation does not exactly
> > instill me with confidence in your opinion- I'd like to see you explain
> > why the software I wrote and am now using in production cannot possibly
> > work as intended. Again do me a favor and test it if you cannot figure
> > out how it works from source:
>
> So, I think the disconnect stems from my (apparent) misunderstanding that
> you were seeking an automated solution that was available *today* to this
> very incubator graduate. Something that would allow the users of that
> codebase to effectively not even really notice that the project has been
> moved elsewhere in the repository. Sorry for not noticing that the thread
> had shifted into a consideration of some as-yet-uncharted future.
>
> > % svn co
> http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000
> > % cd trunk
> > % svn up
> >
> > Post the output if you do not understand what our
> > server is trying to convey when you issue those commands.
>
> Well, I see this (using an 1.8.0-dev Subversion client):
>
> {{{
> $ svn co
> http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000
> A trunk/singlewebapp
> A trunk/singlewebapp/test
> A trunk/singlewebapp/test/filename1.wml
> A trunk/debian_package/etc/init.d
> A trunk/debian_package/etc/init.d/ooomeetings
> A trunk/debian_package/etc/init.d/red5-openmeetings
> Checked out revision 1400000.
> $ cd trunk/
> $ svn up
> Updating '.':
> subversion/svn/update-cmd.c:175: (apr_err=175011)
> subversion/libsvn_client/update.c:625: (apr_err=175011)
> subversion/libsvn_client/update.c:565: (apr_err=175011)
> subversion/libsvn_client/update.c:381: (apr_err=175011)
> subversion/libsvn_client/iprops.c:273: (apr_err=175011)
> subversion/libsvn_client/iprops.c:217: (apr_err=175011)
Looking at this stack, this error originates in the iprops fetch that was added before the actual update for 1.8.
Bert
> subversion/libsvn_ra/ra_loader.c:1323: (apr_err=175011)
> subversion/libsvn_ra/compat.c:914: (apr_err=175011)
> subversion/libsvn_ra_serf/serf.c:1081: (apr_err=175011)
> subversion/libsvn_ra_serf/property.c:694: (apr_err=175011)
> subversion/libsvn_ra_serf/property.c:670: (apr_err=175011)
> subversion/libsvn_ra_serf/util.c:2376: (apr_err=175011)
> svn: E175011: Repository moved permanently to '(null)'; please relocate
> $
> }}}
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/05/2013 04:56 PM, Joe Schaefer wrote:
> Telling me this is a dead-end task without explanation does not exactly
> instill me with confidence in your opinion- I'd like to see you explain
> why the software I wrote and am now using in production cannot possibly
> work as intended. Again do me a favor and test it if you cannot figure
> out how it works from source:
So, I think the disconnect stems from my (apparent) misunderstanding that
you were seeking an automated solution that was available *today* to this
very incubator graduate. Something that would allow the users of that
codebase to effectively not even really notice that the project has been
moved elsewhere in the repository. Sorry for not noticing that the thread
had shifted into a consideration of some as-yet-uncharted future.
> % svn co http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000
> % cd trunk
> % svn up
>
> Post the output if you do not understand what our
> server is trying to convey when you issue those commands.
Well, I see this (using an 1.8.0-dev Subversion client):
{{{
$ svn co http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000
A trunk/singlewebapp
A trunk/singlewebapp/test
A trunk/singlewebapp/test/filename1.wml
A trunk/debian_package/etc/init.d
A trunk/debian_package/etc/init.d/ooomeetings
A trunk/debian_package/etc/init.d/red5-openmeetings
Checked out revision 1400000.
$ cd trunk/
$ svn up
Updating '.':
subversion/svn/update-cmd.c:175: (apr_err=175011)
subversion/libsvn_client/update.c:625: (apr_err=175011)
subversion/libsvn_client/update.c:565: (apr_err=175011)
subversion/libsvn_client/update.c:381: (apr_err=175011)
subversion/libsvn_client/iprops.c:273: (apr_err=175011)
subversion/libsvn_client/iprops.c:217: (apr_err=175011)
subversion/libsvn_ra/ra_loader.c:1323: (apr_err=175011)
subversion/libsvn_ra/compat.c:914: (apr_err=175011)
subversion/libsvn_ra_serf/serf.c:1081: (apr_err=175011)
subversion/libsvn_ra_serf/property.c:694: (apr_err=175011)
subversion/libsvn_ra_serf/property.c:670: (apr_err=175011)
subversion/libsvn_ra_serf/util.c:2376: (apr_err=175011)
svn: E175011: Repository moved permanently to '(null)'; please relocate
$
}}}
But I suspect that's not precisely what you see.
From this I gather the server has issued a Redirect. Indeed, from a
wireshark trace, I see the Redirect was of the 301 variety and contains this
header:
Location: http://svn.apache.org/repos/asf/openmeetings
So, looks good so far. It seems the client has a problem properly parsing
the header -- something we need to fix if that hasn't been done already.
> Again the source code for my module is at
> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path
>
> As I said earlier, the reason we are bandying about relocate is because
> that's how you coded up the solution to Jon's ticket. I again don't see
> the difficulty in interrogating the target server's UUID on a 301 and
> determining whether or not a relocate is warranted over a simple svn
> switch- please enlighten me on the difficulties.
Oh, I'm not saying that it can't be done using some future version of
Subversion that chooses switch or relocate as needed. (See
"misunderstanding" above.)
> Let's move forward with an honest technical discussion based on actual
> research on existing solution instead of arguing from authority and
> continuing to discuss social failings instead of technical ones. Thx in
> advance.
Agreed.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
Telling me this is a dead-end task without
explanation does not exactly instill me with
confidence in your opinion- I'd like to see
you explain why the software I wrote and am
now using in production cannot possibly work
as intended. Again do me a favor and test
it if you cannot figure out how it works from
source:
% svn co http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000
% cd trunk
% svn up
Post the output if you do not understand what our
server is trying to convey when you issue those commands.
Again the source code for my module is at
https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path
As I said earlier, the reason we are bandying about
relocate is because that's how you coded up the
solution to Jon's ticket. I again don't see the
difficulty in interrogating the target server's
UUID on a 301 and determining whether or not a
relocate is warranted over a simple svn switch-
please enlighten me on the difficulties.
Let's move forward with an honest technical discussion
based on actual research on existing solution instead
of arguing from authority and continuing to discuss social
failings instead of technical ones. Thx in advance.
>________________________________
> From: C. Michael Pilato <cm...@collab.net>
>To: Joe Schaefer <jo...@yahoo.com>
>Cc: Branko Čibej <br...@wandisco.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>Sent: Tuesday, February 5, 2013 4:46 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>Uh... I'm not sure what I said that put me on a "high horse". That is,
>unless my trying to save you spending additional energy on what is (from my
>perspective) a dead-end task somehow qualifies.
>
>At any rate, if I was emitting negativity, it wasn't aimed at you, but at
>the fact that the related thread had somehow been allowed to continue for so
>long before someone realized that "relocate" isn't even the right action for
>the job. That's not a fault of yours, by any stretch -- we devs are
>*supposed* to be the experts here, but seemingly failed to notice this
>little detail.
>
>All that said, I suspect you understand the world well enough to figure out
>that just because civility starts to degrade (or appears to start degrading)
>doesn't mean that you are compelled to accelerate its decline. Please don't
>bring poisonous name-slinging into this community -- it is quite unwelcome.
>
>-- C-Mike
>
>On 02/05/2013 02:04 PM, Joe Schaefer wrote:
>> It was civil until CMike got on his high horse- you need to police
>> yourselves a bit better before you start accusing outsiders of
>> misbehavior- that's how civility starts degrading in a project.
>>
>> The fact is that a robust solution involves coding thisup as part of the
>> generic exception handlingmechanics for whatever svn ops can deal
>> with301s. What's currently in 1.7 that we're pretendingautomates the
>> redirect problem is inadequate forany serious svn http server
>> administrator trying to track moves. This is not an idle question-
>> Daniel actually tried putting a Redirect block in for the openejb ->
>> tomee rename and all it wound up doing is destroying any attempts to
>> crawl the project's pre-move history. We had to back out the change just
>> to let our git-svn mirror pick up the new tomee location and DTRT with
>> the history.
>>
>> Please go ahead and test the current server behavior for svn.apache.org
>> to see how existing svn clients respond pre-and-post podling graduation.
>> The server support and the client-side error reporting are already
>> there.
>>
>> ----------------------------------------------------------------------------
>>
>>
>*From:* Branko Čibej <br...@wandisco.com>
>> *To:* "dev@subversion.apache.org" <de...@subversion.apache.org> *Sent:*
>> Tuesday, February 5, 2013 1:52 PM *Subject:* Re: Coniguring 301/302
>> redirects to track an fspath rename
>>
>> a) I know it's not a call for infra to make b) if you can't lead a civil
>> conversation, you may as well send it to /dev/null for all the good it'll
>> do.
>>
>> -- Brane
>>
>> On 05.02.2013 18:36, Joe Schaefer wrote:
>>> AFAICT if I really wanted this feature myself I could write a perl
>>> script that wraps svn client calls and DTRT with the error message in
>>> less than 20 LOC. You don't have to act like dicks towards people who
>>> are trying to take advantage of newer features you ostensibly support-
>>> the only reason we're discussing relocation features is because that's
>>> all you currently offer. If you start supporting in-repo switch ops,
>>> hallelujah.
>>>
>>>
>>>
>>>
>> ------------------------------------------------------------------------
>>> *From:* Joe Schaefer <joe_schaefer@yahoo.com
>> <ma...@yahoo.com>>
>>> *To:* Branko Čibej <brane@wandisco.com <ma...@wandisco.com>>;
>>> "dev@subversion.apache.org <ma...@subversion.apache.org>"
>> <dev@subversion.apache.org <ma...@subversion.apache.org>>
>>> *Sent:* Tuesday, February 5, 2013 12:08 PM *Subject:* Re: Coniguring
>>> 301/302 redirects to track an fspath rename
>>>
>>> 1) that's not a decision for infra to make. 2) the svn client even with
>>> 1.6 now reports the proper error message indicating the location of the
>>> new url. All infra needs is for the svn client to provide a config
>>> option to actually interpret the error status and take meaningful
>>> action itself. This doesn't sound like rocket science to me, no matter
>>> how screwed up the current level of support for redirects may be.
>>>
>>>
>>>
>> ------------------------------------------------------------------------
>>> *From:* Branko Čibej <brane@wandisco.com
>> <ma...@wandisco.com>>
>>> *To:* dev@subversion.apache.org <ma...@subversion.apache.org>
>>> *Sent:* Tuesday, February 5, 2013 11:50 AM *Subject:* Re: Coniguring
>>> 301/302 redirects to track an fspath rename
>>>
>>> On 05.02.2013 16:07, C. Michael Pilato wrote:
>>>> So, I hate to be the bearer of bad tidings, but this entire
>>> exercise
>>>> is a giant waste of time and energy.
>>>
>>> I was going to say it'd be much better overall to create podling trees
>>> in SVN in the location they'd have when they graduate, as has already
>>> been half-way done with mailing lists.
>>>
>>> -- Brane
>>>
>>> -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
>> <http://www.wandisco.com/>
>>> <http://www.wandisco.com/>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
>>
>>
>>
>
>
>--
>C. Michael Pilato <cm...@collab.net>
>CollabNet <> www.collab.net <> Enterprise Cloud Development
>
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by "C. Michael Pilato" <cm...@collab.net>.
Uh... I'm not sure what I said that put me on a "high horse". That is,
unless my trying to save you spending additional energy on what is (from my
perspective) a dead-end task somehow qualifies.
At any rate, if I was emitting negativity, it wasn't aimed at you, but at
the fact that the related thread had somehow been allowed to continue for so
long before someone realized that "relocate" isn't even the right action for
the job. That's not a fault of yours, by any stretch -- we devs are
*supposed* to be the experts here, but seemingly failed to notice this
little detail.
All that said, I suspect you understand the world well enough to figure out
that just because civility starts to degrade (or appears to start degrading)
doesn't mean that you are compelled to accelerate its decline. Please don't
bring poisonous name-slinging into this community -- it is quite unwelcome.
-- C-Mike
On 02/05/2013 02:04 PM, Joe Schaefer wrote:
> It was civil until CMike got on his high horse- you need to police
> yourselves a bit better before you start accusing outsiders of
> misbehavior- that's how civility starts degrading in a project.
>
> The fact is that a robust solution involves coding thisup as part of the
> generic exception handlingmechanics for whatever svn ops can deal
> with301s. What's currently in 1.7 that we're pretendingautomates the
> redirect problem is inadequate forany serious svn http server
> administrator trying to track moves. This is not an idle question-
> Daniel actually tried putting a Redirect block in for the openejb ->
> tomee rename and all it wound up doing is destroying any attempts to
> crawl the project's pre-move history. We had to back out the change just
> to let our git-svn mirror pick up the new tomee location and DTRT with
> the history.
>
> Please go ahead and test the current server behavior for svn.apache.org
> to see how existing svn clients respond pre-and-post podling graduation.
> The server support and the client-side error reporting are already
> there.
>
> ----------------------------------------------------------------------------
>
>
*From:* Branko Čibej <br...@wandisco.com>
> *To:* "dev@subversion.apache.org" <de...@subversion.apache.org> *Sent:*
> Tuesday, February 5, 2013 1:52 PM *Subject:* Re: Coniguring 301/302
> redirects to track an fspath rename
>
> a) I know it's not a call for infra to make b) if you can't lead a civil
> conversation, you may as well send it to /dev/null for all the good it'll
> do.
>
> -- Brane
>
> On 05.02.2013 18:36, Joe Schaefer wrote:
>> AFAICT if I really wanted this feature myself I could write a perl
>> script that wraps svn client calls and DTRT with the error message in
>> less than 20 LOC. You don't have to act like dicks towards people who
>> are trying to take advantage of newer features you ostensibly support-
>> the only reason we're discussing relocation features is because that's
>> all you currently offer. If you start supporting in-repo switch ops,
>> hallelujah.
>>
>>
>>
>>
> ------------------------------------------------------------------------
>> *From:* Joe Schaefer <joe_schaefer@yahoo.com
> <ma...@yahoo.com>>
>> *To:* Branko Čibej <brane@wandisco.com <ma...@wandisco.com>>;
>> "dev@subversion.apache.org <ma...@subversion.apache.org>"
> <dev@subversion.apache.org <ma...@subversion.apache.org>>
>> *Sent:* Tuesday, February 5, 2013 12:08 PM *Subject:* Re: Coniguring
>> 301/302 redirects to track an fspath rename
>>
>> 1) that's not a decision for infra to make. 2) the svn client even with
>> 1.6 now reports the proper error message indicating the location of the
>> new url. All infra needs is for the svn client to provide a config
>> option to actually interpret the error status and take meaningful
>> action itself. This doesn't sound like rocket science to me, no matter
>> how screwed up the current level of support for redirects may be.
>>
>>
>>
> ------------------------------------------------------------------------
>> *From:* Branko Čibej <brane@wandisco.com
> <ma...@wandisco.com>>
>> *To:* dev@subversion.apache.org <ma...@subversion.apache.org>
>> *Sent:* Tuesday, February 5, 2013 11:50 AM *Subject:* Re: Coniguring
>> 301/302 redirects to track an fspath rename
>>
>> On 05.02.2013 16:07, C. Michael Pilato wrote:
>>> So, I hate to be the bearer of bad tidings, but this entire
>> exercise
>>> is a giant waste of time and energy.
>>
>> I was going to say it'd be much better overall to create podling trees
>> in SVN in the location they'd have when they graduate, as has already
>> been half-way done with mailing lists.
>>
>> -- Brane
>>
>> -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
> <http://www.wandisco.com/>
>> <http://www.wandisco.com/>
>>
>>
>>
>>
>>
>
>
> -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
>
>
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
It was civil until CMike got on his
high horse- you need to police yourselves
a bit better before you start accusing
outsiders of misbehavior- that's how civility
starts degrading in a project.
The fact is that a robust solution involves
coding thisup as part of the generic exception
handlingmechanics for whatever svn ops can deal
with301s. What's currently in 1.7 that we're
pretendingautomates the redirect problem is inadequate
forany serious svn http server administrator trying
to track moves. This is not an idle question-
Daniel actually tried putting a Redirect block
in for the openejb -> tomee rename and all it wound
up doing is destroying any attempts to crawl
the project's pre-move history. We had to back
out the change just to let our git-svn mirror
pick up the new tomee location and DTRT with the
history.
Please go ahead and test the current server behavior
for svn.apache.org to see how existing svn clients
respond pre-and-post podling graduation. The server
support and the client-side error reporting are already
there.
>________________________________
> From: Branko Čibej <br...@wandisco.com>
>To: "dev@subversion.apache.org" <de...@subversion.apache.org>
>Sent: Tuesday, February 5, 2013 1:52 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>a) I know it's not a call for infra to make
>b) if you can't lead a civil conversation, you may as well send it to
>/dev/null for all the good it'll do.
>
>-- Brane
>
>On 05.02.2013 18:36, Joe Schaefer wrote:
>> AFAICT if I really wanted this feature myself
>> I could write a perl script that wraps svn client calls
>> and DTRT with the error message in less than 20 LOC.
>> You don't have to act like dicks towards people
>> who are trying to take advantage of newer features
>> you ostensibly support- the only reason we're discussing
>> relocation features is because that's all you currently
>> offer. If you start supporting in-repo switch ops,
>> hallelujah.
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Joe Schaefer <jo...@yahoo.com>
>> *To:* Branko Čibej <br...@wandisco.com>;
>> "dev@subversion.apache.org" <de...@subversion.apache.org>
>> *Sent:* Tuesday, February 5, 2013 12:08 PM
>> *Subject:* Re: Coniguring 301/302 redirects to track an fspath rename
>>
>> 1) that's not a decision for infra to make.
>> 2) the svn client even with 1.6 now reports
>> the proper error message indicating the location
>> of the new url. All infra needs is for the svn client
>> to provide a config option to actually interpret
>> the error status and take meaningful action itself.
>> This doesn't sound like rocket science to me,
>> no matter how screwed up the current level of
>> support for redirects may be.
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Branko Čibej <br...@wandisco.com>
>> *To:* dev@subversion.apache.org
>> *Sent:* Tuesday, February 5, 2013 11:50 AM
>> *Subject:* Re: Coniguring 301/302 redirects to track an fspath
>> rename
>>
>> On 05.02.2013 16:07, C. Michael Pilato wrote:
>> > So, I hate to be the bearer of bad tidings, but this entire
>> exercise
>> > is a giant waste of time and energy.
>>
>> I was going to say it'd be much better overall to create
>> podling trees
>> in SVN in the location they'd have when they graduate, as has
>> already
>> been half-way done with mailing lists.
>>
>> -- Brane
>>
>> --
>> Branko Čibej
>> Director of Subversion | WANdisco | www.wandisco.com
>> <http://www.wandisco.com/>
>>
>>
>>
>>
>>
>
>
>--
>Branko Čibej
>Director of Subversion | WANdisco | www.wandisco.com
>
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Branko Čibej <br...@wandisco.com>.
a) I know it's not a call for infra to make
b) if you can't lead a civil conversation, you may as well send it to
/dev/null for all the good it'll do.
-- Brane
On 05.02.2013 18:36, Joe Schaefer wrote:
> AFAICT if I really wanted this feature myself
> I could write a perl script that wraps svn client calls
> and DTRT with the error message in less than 20 LOC.
> You don't have to act like dicks towards people
> who are trying to take advantage of newer features
> you ostensibly support- the only reason we're discussing
> relocation features is because that's all you currently
> offer. If you start supporting in-repo switch ops,
> hallelujah.
>
>
>
> ------------------------------------------------------------------------
> *From:* Joe Schaefer <jo...@yahoo.com>
> *To:* Branko Čibej <br...@wandisco.com>;
> "dev@subversion.apache.org" <de...@subversion.apache.org>
> *Sent:* Tuesday, February 5, 2013 12:08 PM
> *Subject:* Re: Coniguring 301/302 redirects to track an fspath rename
>
> 1) that's not a decision for infra to make.
> 2) the svn client even with 1.6 now reports
> the proper error message indicating the location
> of the new url. All infra needs is for the svn client
> to provide a config option to actually interpret
> the error status and take meaningful action itself.
> This doesn't sound like rocket science to me,
> no matter how screwed up the current level of
> support for redirects may be.
>
>
> ------------------------------------------------------------------------
> *From:* Branko Čibej <br...@wandisco.com>
> *To:* dev@subversion.apache.org
> *Sent:* Tuesday, February 5, 2013 11:50 AM
> *Subject:* Re: Coniguring 301/302 redirects to track an fspath
> rename
>
> On 05.02.2013 16:07, C. Michael Pilato wrote:
> > So, I hate to be the bearer of bad tidings, but this entire
> exercise
> > is a giant waste of time and energy.
>
> I was going to say it'd be much better overall to create
> podling trees
> in SVN in the location they'd have when they graduate, as has
> already
> been half-way done with mailing lists.
>
> -- Brane
>
> --
> Branko Čibej
> Director of Subversion | WANdisco | www.wandisco.com
> <http://www.wandisco.com/>
>
>
>
>
>
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
AFAICT if I really wanted this feature myself
I could write a perl script that wraps svn client calls
and DTRT with the error message in less than 20 LOC.
You don't have to act like dicks towards people
who are trying to take advantage of newer features
you ostensibly support- the only reason we're discussing
relocation features is because that's all you currently
offer. If you start supporting in-repo switch ops,
hallelujah.
>________________________________
> From: Joe Schaefer <jo...@yahoo.com>
>To: Branko Čibej <br...@wandisco.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>Sent: Tuesday, February 5, 2013 12:08 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>
>1) that's not a decision for infra to make.
>2) the svn client even with 1.6 now reports
>the proper error message indicating the location
>of the new url. All infra needs is for the svn client
>to provide a config option to actually interpret
>the error status and take meaningful action itself.
>This doesn't sound like rocket science to me,
>no matter how screwed up the current level of
>support for redirects may be.
>
>
>
>
>
>
>>________________________________
>> From: Branko Čibej <br...@wandisco.com>
>>To: dev@subversion.apache.org
>>Sent: Tuesday, February 5, 2013 11:50 AM
>>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>>On 05.02.2013 16:07, C. Michael Pilato wrote:
>>> So, I hate to be the bearer of bad tidings, but this entire exercise
>>> is a giant waste of time and energy.
>>
>>I was going to say it'd be much better overall to create podling trees
>>in SVN in the location they'd have when they graduate, as has already
>>been half-way done with mailing lists.
>>
>>-- Brane
>>
>>--
>>Branko Čibej
>>Director of Subversion | WANdisco | www.wandisco.com
>>
>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
1) that's not a decision for infra to make.
2) the svn client even with 1.6 now reports
the proper error message indicating the location
of the new url. All infra needs is for the svn client
to provide a config option to actually interpret
the error status and take meaningful action itself.
This doesn't sound like rocket science to me,
no matter how screwed up the current level of
support for redirects may be.
>________________________________
> From: Branko Čibej <br...@wandisco.com>
>To: dev@subversion.apache.org
>Sent: Tuesday, February 5, 2013 11:50 AM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>On 05.02.2013 16:07, C. Michael Pilato wrote:
>> So, I hate to be the bearer of bad tidings, but this entire exercise
>> is a giant waste of time and energy.
>
>I was going to say it'd be much better overall to create podling trees
>in SVN in the location they'd have when they graduate, as has already
>been half-way done with mailing lists.
>
>-- Brane
>
>--
>Branko Čibej
>Director of Subversion | WANdisco | www.wandisco.com
>
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Branko Čibej <br...@wandisco.com>.
On 05.02.2013 16:07, C. Michael Pilato wrote:
> So, I hate to be the bearer of bad tidings, but this entire exercise
> is a giant waste of time and energy.
I was going to say it'd be much better overall to create podling trees
in SVN in the location they'd have when they graduate, as has already
been half-way done with mailing lists.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/04/2013 10:57 PM, Greg Stein wrote:
> 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
That's not ... entirely ... true. In 1.7, I actually did teach Subversion's
update functionality to automatically relocate the working copy if the
server sends a permanent redirect during whatever requests comprise the
svn_ra_open() handling.
The problem I see with all of the chatter in this thread is that 'relocate'
is precisely the *wrong* action for the user to take. If the repository
directory has simply been moved to some other place in the same repository,
this calls for a regular 'svn switch'. Relocation is a metadata-only
transformation within the working copy, which tweaks the repos_root_url and
repos_relpath as a way of dealing with the situation where a whole
repository has been moved to/exposed at a different URL. You need something
here that operates *within the same repository* and which traverses not just
space (URLs) but time also (revisions). That's 'svn switch'. We have no
client-side automated support for 'svn switch'ing to a new location.
So, I hate to be the bearer of bad tidings, but this entire exercise is a
giant waste of time and energy.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
Thanks Greg, that clears things up for me.
>________________________________
> From: Greg Stein <gs...@gmail.com>
>To: Joe Schaefer <jo...@yahoo.com>
>Cc: "dev@subversion.apache.org" <de...@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 <jo...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>> To: Joe Schaefer <jo...@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" <jo...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>> To: Greg Stein <gs...@gmail.com>
>> Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>> To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>> To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>> Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Greg Stein <gs...@gmail.com>.
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 <jo...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
> To: Joe Schaefer <jo...@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" <jo...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> To: Greg Stein <gs...@gmail.com>
> Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
> To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
> To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
> Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>To: Greg Stein <gs...@gmail.com>
>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>To: Greg Stein <gs...@gmail.com>
>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>To: Greg Stein <gs...@gmail.com>
>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>>>To: Joe Schaefer <jo...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>>>>>>>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>>>>>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>To: Greg Stein <gs...@gmail.com>
>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>To: Greg Stein <gs...@gmail.com>
>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>To: Greg Stein <gs...@gmail.com>
>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>>To: Joe Schaefer <jo...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>>>>>>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>>>>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
Damn, processing updates requires fishing little
details out of a REPORT request body. This is getting
complicated...
>________________________________
> From: Joe Schaefer <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>To: Greg Stein <gs...@gmail.com>
>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>To: Greg Stein <gs...@gmail.com>
>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>To: Greg Stein <gs...@gmail.com>
>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>To: Joe Schaefer <jo...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>>>>>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>>>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>To: Greg Stein <gs...@gmail.com>
>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>To: Greg Stein <gs...@gmail.com>
>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>To: Greg Stein <gs...@gmail.com>
>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>To: Joe Schaefer <jo...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>>>>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>To: Greg Stein <gs...@gmail.com>
>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>To: Greg Stein <gs...@gmail.com>
>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>To: Joe Schaefer <jo...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>>>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>To: Greg Stein <gs...@gmail.com>
>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>To: Joe Schaefer <jo...@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" <jo...@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 <jo...@yahoo.com>
>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>To: Joe Schaefer <jo...@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" <jo...@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 <jo...@yahoo.com>
>>>>To: Greg Stein <gs...@gmail.com>
>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <gs...@gmail.com>
>To: Joe Schaefer <jo...@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" <jo...@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 <jo...@yahoo.com>
>>>To: Greg Stein <gs...@gmail.com>
>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>To: Greg Stein <gs...@gmail.com>
>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Greg Stein <gs...@gmail.com>.
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" <jo...@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 <jo...@yahoo.com>
> *To:* Greg Stein <gs...@gmail.com>
> *Cc:* "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> *To:* Greg Stein <gs...@gmail.com>
> *Cc:* "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> *To:* Greg Stein <gs...@gmail.com>
> *Cc:* "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> *To:* Greg Stein <gs...@gmail.com>
> *Cc:* "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> *To:* Greg Stein <gs...@gmail.com>
> *Cc:* "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
> *To:* Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
> *To:* 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <
> bert@qqmail.nl>
> *Cc:* "dev@subversion.apache.org" <de...@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 <be...@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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
In any case Daniel, what this boils down to is that we
need some way of distinguishing OPTIONS requests from svn
update that want HEAD, from operations that want something
older, in which case we probably shouldn't interfere with
the request. Having a specific revision number on the OPTIONS
request works but isn't actually essential to our use case.
Just try to keep in mind here that my role in this is to try
and help *you* Daniel- my original position when youfirst
mentioned this idea to me was similar to Ben's- that it
is unwise to introduce http redirects into an svn server's
url space.
----- Original Message -----
> From: Daniel Shahaf <d....@daniel.shahaf.name>
> To: Joe Schaefer <jo...@yahoo.com>
> Cc: Greg Stein <gs...@gmail.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
> Sent: Monday, February 4, 2013 2:53 AM
> Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
> Joe Schaefer wrote on Sun, Feb 03, 2013 at 13:40:11 -0800:
>> >________________________________
>> > From: Daniel Shahaf <d....@daniel.shahaf.name>
>> >To: Joe Schaefer <jo...@yahoo.com>
>> >Cc: Greg Stein <gs...@gmail.com>;
> "dev@subversion.apache.org" <de...@subversion.apache.org>
>> >Sent: Sunday, February 3, 2013 4:15 PM
>> >Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>> >
>> >I already told you Joe: go over existing callers of svn_ra_open4() and
>> >see what value each of them could provide as the ?p= argument.
>>
>>
>> Thanks for barking more orders at me- I'd prefer collaboration where
>
> I wasn't.
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Joe Schaefer wrote on Sun, Feb 03, 2013 at 13:40:11 -0800:
> >________________________________
> > From: Daniel Shahaf <d....@daniel.shahaf.name>
> >To: Joe Schaefer <jo...@yahoo.com>
> >Cc: Greg Stein <gs...@gmail.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
> >Sent: Sunday, February 3, 2013 4:15 PM
> >Subject: Re: Coniguring 301/302 redirects to track an fspath rename
> >
> >I already told you Joe: go over existing callers of svn_ra_open4() and
> >see what value each of them could provide as the ?p= argument.
>
>
> Thanks for barking more orders at me- I'd prefer collaboration where
I wasn't.
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
>________________________________
> From: Daniel Shahaf <d....@daniel.shahaf.name>
>To: Joe Schaefer <jo...@yahoo.com>
>Cc: Greg Stein <gs...@gmail.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
>Sent: Sunday, February 3, 2013 4:15 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>I already told you Joe: go over existing callers of svn_ra_open4() and
>see what value each of them could provide as the ?p= argument.
Thanks for barking more orders at me- I'd prefer collaboration where
possible. It is far easier for me to get some discussion out of the
experts in the room than it is for me to go grepping for things in
the source that I barely understand. I certainly didn't expect you
to write the http module to support this, even tho it's your idea;
please be respectful of the fact that I don't have enough knowledge
about the subversion codebase to provide a desirable patch at this
juncture. Thanks.
>checkout will provide NULL (or maybe SVN_INVALID_REVNUM, if we don't
>make that mean "HEAD").
Pretty sure I've checked out specific revisions of trees using pegrevs
in the past.
>
>cat will provide the operative or peg revision.
>
>update/switch will provide the BASE revision of the update root, or
>something like that (compare the "target revision" concept in the
>editor).
>
>Someone needs to fill in the rest...
I think Greg was trying to point out that the OPTIONS request
is oblivious to the eventual svn operations desired- the only
thing I know for certain is that it knows the proper url to
throw the initial request at. If it knows that much, perhaps
from recalling initial command line args, perhaps the remainder
of those args involving revisions can be provided in the OPTIONS request?
All I really need is some ballpark number to provide meaningful support
for walking through the history of a graduated podling;
right now the tools available to a http server admin trying
to work with the fledgling redirect support in newer svn
clients are inadequate for the ASF's use case, as I'm sure you
know Daniel.
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
I already told you Joe: go over existing callers of svn_ra_open4() and
see what value each of them could provide as the ?p= argument.
checkout will provide NULL (or maybe SVN_INVALID_REVNUM, if we don't
make that mean "HEAD").
cat will provide the operative or peg revision.
update/switch will provide the BASE revision of the update root, or
something like that (compare the "target revision" concept in the
editor).
Someone needs to fill in the rest...
Joe Schaefer wrote on Sun, Feb 03, 2013 at 11:33:30 -0800:
> 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 <jo...@yahoo.com>
> >To: Greg Stein <gs...@gmail.com>
> >Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> >>To: Greg Stein <gs...@gmail.com>
> >>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> >>>To: Greg Stein <gs...@gmail.com>
> >>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> >>>>To: Greg Stein <gs...@gmail.com>
> >>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
> >>>>>To: Greg Stein <gs...@gmail.com>
> >>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
> >>>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
> >>>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
> >>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>To: Greg Stein <gs...@gmail.com>
>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>To: Greg Stein <gs...@gmail.com>
>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>To: Greg Stein <gs...@gmail.com>
>>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>>To: Greg Stein <gs...@gmail.com>
>>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>To: Greg Stein <gs...@gmail.com>
>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>To: Greg Stein <gs...@gmail.com>
>>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>>To: Greg Stein <gs...@gmail.com>
>>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>To: Greg Stein <gs...@gmail.com>
>>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>>To: Greg Stein <gs...@gmail.com>
>>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <jo...@yahoo.com>
>>To: Greg Stein <gs...@gmail.com>
>>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: Greg Stein <gs...@gmail.com>
>Cc: "dev@subversion.apache.org" <de...@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 <gs...@gmail.com>
>>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
The redirects logic happens in svn_ra_open4(), so you'll want to have it
grow an optional svn_revnum_t parameter (that can take the values NULL
or HEAD or an integer), which svn_ra_serf__open() would then tack on to
the request for your custom module to intercept.
'svn checkout' won't populate the new optional parameter, but 'svn ls
foo@peg' and update/checkout could conceivably populate it. I'm just
not sure how far the revnum value is from the svn_ra_open4 call.
Joe Schaefer wrote on Fri, Feb 01, 2013 at 23:07:43 -0800:
> 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 <gs...@gmail.com>
> >To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
> >>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
> >>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >
> >
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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" <jo...@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 <gs...@gmail.com>
> > *To:* Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
> > *To:* 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <
> > bert@qqmail.nl>
> > *Cc:* "dev@subversion.apache.org" <de...@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 <be...@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
> >
> >
> >
> >
> >
> >
> >
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Greg Stein <gs...@gmail.com>.
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" <jo...@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 <gs...@gmail.com>
> *To:* Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
> *To:* 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <
> bert@qqmail.nl>
> *Cc:* "dev@subversion.apache.org" <de...@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 <be...@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
>
>
>
>
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <gs...@gmail.com>
>To: Joe Schaefer <jo...@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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>>>>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>>>>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Greg Stein <gs...@gmail.com>.
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" <gs...@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" <jo...@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 <jo...@yahoo.com>
>> *To:* 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <
>> bert@qqmail.nl>
>> *Cc:* "dev@subversion.apache.org" <de...@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 <be...@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
>>
>>
>>
>>
>>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Greg Stein <gs...@gmail.com>.
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" <jo...@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 <jo...@yahoo.com>
> *To:* 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <
> bert@qqmail.nl>
> *Cc:* "dev@subversion.apache.org" <de...@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 <be...@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
>
>
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <jo...@yahoo.com>
>To: 'Daniel Shahaf' <d....@daniel.shahaf.name>; Bert Huijben <be...@qqmail.nl>
>Cc: "dev@subversion.apache.org" <de...@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 <be...@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
>>
>>
>>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Joe Schaefer <jo...@yahoo.com>.
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 <be...@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
>
>
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Sat, Feb 02, 2013 at 11:20:05 +0100:
> On 01.02.2013 21:33, 'Daniel Shahaf' wrote:
> > Bert Huijben wrote on Fri, Feb 01, 2013 at 21:28:10 +0100:
> >> 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'd have thought a proxy would be easier to set up, and more
> bullet-proof, since it wouldn't depend on magic happening in the client.
>
Thta doesn't solve the problem --- even if you did a transparent proxy
from /incubator/foo to /foo, you'd still have the problem of allowing
access to historical (pre-rename) revisions of /incubator/foo.
(unless the proxy is somehow peg-revision-aware and translates
'svn ls /incubator/foo@42' to 'svn ls -r42 /foo@HEAD'.)
> Sure, proxying eats more server resources than redirecting.
>
> -- Brane
>
> --
> Branko Čibej
> Director of Subversion | WANdisco | www.wandisco.com
>
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by Branko Čibej <br...@wandisco.com>.
On 01.02.2013 21:33, 'Daniel Shahaf' wrote:
> Bert Huijben wrote on Fri, Feb 01, 2013 at 21:28:10 +0100:
>> 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'd have thought a proxy would be easier to set up, and more
bullet-proof, since it wouldn't depend on magic happening in the client.
Sure, proxying eats more server resources than redirecting.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Coniguring 301/302 redirects to track an fspath rename
Posted by 'Daniel Shahaf' <d....@daniel.shahaf.name>.
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
RE: Coniguring 301/302 redirects to track an fspath rename
Posted by Bert Huijben <be...@qqmail.nl>.
> -----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.
Why not just leave a top level folder with some readme?
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?)
Bert