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

Re: [PATCH] Make vanilla switch capable of changing the repository root

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Tue, 02 Sep 2008 13:26:39 -0400

"Vlad Georgescu" <vgeorgescu_at_gmail.com> writes:
>> * "svn switch" will quietly perform an "svn relocate" or a current
>> "svn switch" or both, depending on the URL it is given?
> The repos root relocation is not performed as an extra step, but in
> the post-update cleanup phase, at the same time that revisions and
> URL's are rewritten for the entire working copy.

I see two different conversations going on here.

Julian is asking about the user-visible behavior. Vlad is answering
with the under-the-hood implementation.

This thread should be only about the user-visible behavior. That's the
only thing that matters to our users.

>> Also, what will be the standard way to do a relocate? "svn switch" or
>> "svn relocate"? We need one standard way.
> Switch, normally, because it only needs one URL and it updates your WC.

That "normally, " is going to be very hard to explain to users.

>> May I recommend that we do EITHER but not both of:
>> * add "svn relocate" and deprecate "--relocate" as above, but do not
>> let plain "switch" do relocations; or
> I don't see anything wrong with switch doing the right thing if given
> a URL in another repo, regardless of what we do about relocate.

What's (potentially) wrong is that it will confuse our users into
thinking that two different operations are the same thing. Then in the
few cases when the difference causes something to not work, the user
will be even less mentally equipped to deal with it than they are right

I think allowing 'switch' to silently change repositories is going to
cause as much confusion in the long run as the current situation does.

> There are valid uses of --relocate that switch wouldn't cover:
> relocating without updating, changing the scheme part of the URL, etc.
> I don't think they're important but if we need to keep them I'd prefer
> them to be moved to a separate subcommand.

Why are these not important? I've had to change schemes before; I'm
sure I'm not the only one.

> We shouldn't try to second guess users' intentions, even if the use
> case is obscure. Ideally, switch would check that the source and
> target have common ancestry, end error out otherwise (unless maybe a
> --ignore-ancestry flag is given). That would also take care of your
> concern.

But then shouldn't plain 'switch' succeed in every case where relocate
would succeed... ?

I'm still not sure I see the net benefit here.

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-02 19:26:54 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.