[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: Vlad Georgescu <vgeorgescu_at_gmail.com>
Date: Fri, 29 Aug 2008 18:00:57 +0300

On Fri, Aug 29, 2008 at 4:40 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> On Fri, 2008-08-29 at 09:17 -0400, C. Michael Pilato wrote:
>> Vlad Georgescu wrote:
>> > My intention is to remove a limitation of 'svn switch' which would
>> > cover 95% of the use cases for relocate, with a simpler UI. "svn
>> > switch --relocate" will still be there to cover the remaining 5%
>> > (though I'd prefer to move it to a different subcommand to make it
>> > less confusing).
>> +1 on 'svn switch' being more powerful, '--relocate' being deprecated, and
>> 'svn relocate' just being at all.
> Sanity check. (I haven't followed this thread carefully and the proposal
> is not clear from the quote.)
> Are you saying:
> * "svn relocate" will be the new official name for the feature that is
> currently called "svn switch --relocate"; (sounds OK)
> * "svn switch --relocate" will be deprecated in favour of "svn
> relocate"; (sounds OK)


> * "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.

> May I ask, is it anticipated that people will often want to do both
> things (switch to a different branch, and move their repository) at the
> same time?

No, people probably won't want to do that.

OTOH, our externals code does a svn_client_relocate() followed by a
svn_client_switch() if the external URL changes to another repo. With
this patch we could eliminate the relocate.

> I wouldn't have thought so, but, the way I read it, it looks
> like the above proposal is designed to simplify that use case (by making
> "svn switch" do both at once.
> 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.

> 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.

> * make "svn switch" perform a switch or a relocation depending on the
> URL, and deprecate "--relocate" in favour of plain "svn switch".

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.

> In the latter case, I'd strongly recommend not allowing an attempt to do
> both switch and relocate at once: throw an error in that case, as it's
> too likely that the user made a mistake.

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

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-29 17:01:11 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.