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

Re: Possible issue triggered by repos reorg (including repro script)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-04-17 15:29:23 CEST

Greg Hudson <ghudson@MIT.EDU> writes:

> On Sat, 2005-04-16 at 21:44, C. Michael Pilato wrote:
> > Ben Collins-Sussman <sussman@collab.net> writes:
> >
> > > The help text could be improved. I just added more explanation to
> > > chapter 9 in the svn book as well.
> >
> > 'relocate' should have been its own subcommand, distancing itself from
> > the 'switch' operation.
>
> I continue to be mystified at the perception that this would have
> helped. We provide an unsafe operation, confusingly similar in
> semantics to another operation. Everyone who uses the wrong operation
> cites the semantic description of the operations. And yet you (and some
> others) think the major problem is its name?
>
> All we would have accomplished by providing "svn relocate" would be
> increasing the command count, and thus the Subversion learning curve.
> We'd have just as many users confusing relocate with a regular switch.

I disagree. What we've done is bound two completely different
operations (one "unsafe", one not) to the same subcommand, causing
folks to make close mental associations that shouldn't be made.
Instead of letting folks mentally divide subcommands into those which
are and aren't part of daily life, are and aren't "unsafe", we've
mixed a branch-based development operation with a likely uncommon
oh-my-god-they-moved-the-server-and-i-need-to-fix-my-wc operation.

And the command count is completely unrelated to the learning curve.
Should we have gone the following route for the sake of making
Subversion "easier to learn"?

   svn fetch ### for cat
   svn fetch --make-wc ### for checkout
   svn fetch --install ### for update
   svn fetch --install --from ### for switch
   svn fetch --but-no-really --from ### from switch --relocate

No.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 17 15:33:53 2005

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.