You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2013/05/21 23:19:51 UTC

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

Les Mikesell wrote on Tue, May 21, 2013 at 16:04:59 -0500:
> In any case, if you have ever published/announced a URL to your branch
> to the group that will use it, you have a bigger problem than with the
> tool itself if you change that location after the fact.  Rather than
> trying to change history with a move you want to pretend didn't
> happen, maybe it would be better to just do a copy and have everyone
> aware that the location is new.

ASF Infra have an httpd module that intercepts attempts to access a URL
that has been moved (^/incubator/bar/foo to ^/baz/foo) and issues
a permanent redirect (301) response:

https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/README

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Les Mikesell wrote on Tue, May 21, 2013 at 16:40:40 -0500:
> On Tue, May 21, 2013 at 4:19 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Les Mikesell wrote on Tue, May 21, 2013 at 16:04:59 -0500:
> >> In any case, if you have ever published/announced a URL to your branch
> >> to the group that will use it, you have a bigger problem than with the
> >> tool itself if you change that location after the fact.  Rather than
> >> trying to change history with a move you want to pretend didn't
> >> happen, maybe it would be better to just do a copy and have everyone
> >> aware that the location is new.
> >
> > ASF Infra have an httpd module that intercepts attempts to access a URL
> > that has been moved (^/incubator/bar/foo to ^/baz/foo) and issues
> > a permanent redirect (301) response:
> >
> > https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/README
> 
> Does that actually work with svn clients?   Some time ago I tried to
> do a reverse-proxy in apache to a repository hosted on a different

That module just sends a 301 response, it doesn't try to transparently
proxy anything.

Daniel

> server and it worked when the target path was the same on the remote
> as what the client requested but when the path was different and
> mapped in the proxy, somehow the 'real' path leaked back to the client
> and kept it from working for some operations.   Maybe in this case if
> they learn the real path it just works anyway.
> 
> --
>    Les Mikesell
>       lesmikesell@gmail.com

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

Posted by Les Mikesell <le...@gmail.com>.
On Tue, May 21, 2013 at 4:19 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Les Mikesell wrote on Tue, May 21, 2013 at 16:04:59 -0500:
>> In any case, if you have ever published/announced a URL to your branch
>> to the group that will use it, you have a bigger problem than with the
>> tool itself if you change that location after the fact.  Rather than
>> trying to change history with a move you want to pretend didn't
>> happen, maybe it would be better to just do a copy and have everyone
>> aware that the location is new.
>
> ASF Infra have an httpd module that intercepts attempts to access a URL
> that has been moved (^/incubator/bar/foo to ^/baz/foo) and issues
> a permanent redirect (301) response:
>
> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/README

Does that actually work with svn clients?   Some time ago I tried to
do a reverse-proxy in apache to a repository hosted on a different
server and it worked when the target path was the same on the remote
as what the client requested but when the path was different and
mapped in the proxy, somehow the 'real' path leaked back to the client
and kept it from working for some operations.   Maybe in this case if
they learn the real path it just works anyway.

--
   Les Mikesell
      lesmikesell@gmail.com