On Thu, Mar 28, 2002 at 03:44:48PM -0800, Greg Stein wrote:
> 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)
Yeah. I was thinking for unexpected redirects, making the user do a
--force. Like you said aswell, treat temp as just that, and for perm
redirects, redo the .svn/entries URL's.
> > +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.
One other place that Sander pointed out where this would be useful is to
have master read/write repo's, with read-only slaves. Redirect all the
write operations to the master server. Thing is, in this case it is a
"standard" operation (much like what I am doing with the http and https
redirect). Any ideas on how to handle this specially?
--
.------==-=======--------=====------------=-=-----.
/ Ben Collins -- Debian GNU/Linux \
` bcollins@debian.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 01:51:44 2002