On Thu, 2008-08-28 at 22:21 +0300, Vlad Georgescu wrote:
> > I don't understand how that implies to the new world (after your patch)
> > where "switch" can also do a relocate. In the new world, it would seem
> > like relocate could definitely be a flag for svn_client_switch. The
> > flag just disables the update and portion of the switch (and, as a
> > consequence, means the repository-relative part of the URL must be the
> > same for the source and destination).
> Are you suggesting we implement "svn sw --relocate" on top of
> svn_client_switch() + my patch + the new flag? It's possible, but what's the
> point, considering we already have svn_client_relocate() for that?
The implementation should not drive the interface. It may be not worth
the effort to reimplement relocate in terms of switch, but if relocate
is conceptually just "switch with no update" in the new world, then
there is no good argument for giving it a separate subcommand.
> > Also, in the new world, I don't see why relocate needs to take different
> > arguments than switch.
> Assuming you're talking about the command line UI, not API's, don't we need to
> preserve backward compatibility?
Yes. So the literal "svn switch --relocate" can't be made to conform
with switch's arguments, but that's not really an argument for migrating
it to a new subcommand either, since any new syntax wouldn't have
backward compatibility constraints. "svn switch --no-update" would make
as much sense.
---------------------------------------------------------------------
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-28 21:43:01 CEST