[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [rfc] redirects with neon

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-03-29 00:44:48 CET

On Thu, Mar 28, 2002 at 11:03:36PM +0100, Sander Striker wrote:
>...
> > Now, this works on the server side. However, svn fails because it gets a
> > redirect (actually neon fails). Neon does have support for redirects,
> > which is easily enabled via ne_redirect_register(). This only work for
> > same server/port/protocol.

Cool. We definitely should support at least that much.
(although we always want to know when a redirect occurs, even if Neon might
 handle it automatically)

> > So in ra_dav, we need to catch a 302 and rebuild the sessions in this
> > case.
> >
> > Anyone have any comments or gotchas I should watch for in this case?

Well, we really ought to push redirect information back at RA's caller. We
don't want the user to check out /A/B/C, have it redirected to /D, yet the
/A/B/C gets stored into .svn/entries. We'd end up doing the redirects all
the time.

> +1 in doing this, like I said on irc. It will be a usefull feature.

Absolutely. Unlike CVS, it means that we can actually move a repository,
leave a little redirect on the server, and not worry about clients need to
rejigger everything they do.

The tricky part will be telling the app "<that> is now located <here>" and
having it do something smart. Especially if <that> is a whole directory and
everything needs to get shifted recursively.

(think: RA callback table)

Oh. If the redirect is "temporary" then we don't store it back into the
'entries' field. If the redirect is "permanent", then we *do* store it.
(301 is permanent, 302 is temporary)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 29 00:41:17 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.