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

Re: Callbacks, prompts, etc. for issue 2779

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 29 Jul 2010 12:43:23 -0400

On 07/29/2010 12:28 PM, Mark Phippard wrote:
> On Thu, Jul 29, 2010 at 12:24 PM, C. Michael Pilato
> <cmpilato_at_red-bean.com> wrote:
>
>> I was originally thinking "off by default", but only because of the
>> theoretical security implications of being automatically redirected to a URL
>> (possibly a different machine, etc.) that differs from what you expected.
>> Maybe I'm overthinking that, exaggerating the risk? If so -- if there's no
>> risk to automatically following redirection notices -- then is there any
>> value in having either configuration OR prompts for this behavior?
>
> I am just thinking that most people do not plan to need this feature.
> Usually a server moves, or occasionally they enter http instead of
> https and a redirect is in place. If it is not on by default, most
> people are still going to get an error and are unlikely to know to
> turn it on.
>
> If you are a server admin and need to move a server and want to leave
> a redirect behind, we do not give you and tools to also go update all
> your users config's so that they will follow the redirect.

I hear ya. Totally agree.

> If we just do the redirects, might a user just not perceive SVN as being slow?

Well, the redirect should be a one-time event. The working copy is updated
(using svn_client_relocate()) to point to the new, successfully contacted
URL. From then on, it's business as usually for the working copy. It's not
like we're constantly following redirects because the working copy has never
been relocated or anything.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2010-07-29 18:44:04 CEST

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.