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

Re: svnsync - practical applications and plans

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2006-09-12 17:19:54 CEST

On 9/12/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> On Mon, Sep 11, 2006 at 05:22:06PM -0700, Justin Erenkrantz wrote:
> > IMO, SVN shouldn't automatically update the WC with the new base.
> >
> Why not? That would seem to be the perfect response to a permanent
> redirect.

Without asking the user first, it's a violation of the HTTP/1.1 RFC.

RFC 2616 10.3.2 says:

If the 301 status code is received in response to a request other than
GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
(It says the same thing for a 302.)
Imagine that we'd be getting the 301 in response to a PROPFIND at the
beginning of, say, a commit.  In order to execute the 'svn switch
--relocate' internally, we'd have to error out of the commit drive,
prompt the user for confirmation, then execute the relocate (trying to
heuristically determine the WC root resource as 301/302 will give us
the new path for the resource we tried - not the WC root path), then
retry the commit.
BTW, the user could conceivably expect that our automatic rewrite
happen for the entire root of the WC they are in instead of just the
subdir that they are doing the commit in.  And, in fact, if we don't
do that, bad things might happen as we're going to end up splitting
the WC.  (The UUIDs of the repos would match but their URLs wouldn't.)
So, I don't think that's a SMOP nor do I think it's even advisable...  -- justin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 12 18:49:59 2006

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.