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

Re: [PATCH] implement "svn switch --only-rewrite-urls"

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-09-24 06:53:49 CEST

cmpilato@collab.net writes:

> Greg Hudson <ghudson@MIT.EDU> writes:
> > On Mon, 2002-09-23 at 23:19, cmpilato@collab.net wrote:
> > > Could we create an option that at least has a *hope* of being used by
> > > more than one subcommand, like ... oh, "--no-repos-access" or something?
> >
> > Hm. I have a different take on this. I'm happy with the option being
> > very specific to this situation, but I think it should contact the new
> > repository, to ensure that the text bases in the working directory are
> > valid. Otherwise it's too easy to get a corrupt working copy. Didn't
> > this come up previously in the discussion of the command?
> Oh, yeah, it did -- and for what it's worth, I agree with your
> concerns -- but the patch wasn't coded that way, for whatever reason
> (I've not been following the whole discussion). I still am not fond
> of tacking a magical switch onto a single subcommand that is so
> obscure that it will never be used elsewhere -- I mean, just use a new
> subcommand. :-) But whatever.

We just had this conversation, Mike. I think you missed it. :-)

The reason mbk coded it this way was because kfogel specifically asked
him NOT to create a new subcommand. kfogel and others all preferred
not to create a new subcommand, and I agree as well.

The issue is that we don't want to go the way of bitkeeper, creating
new subcommands for every odd edge case that comes along. Many people
find bitkeeper confusing for this reason.

Thus, we'd like to think of this scenario as an edge-case of 'svn
switch', hence the obscure option.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 24 06:55:41 2002

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.