On Sun, 2005-04-17 at 09:29, C. Michael Pilato wrote:
> 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.
I think only your perspective as implementor can justify your position
that they are two completely different operations. Both commands
repoint an existing working directory to a different location.
Certainly, one repoints it at a different repository and one repoints it
at a different location within the repository, which are very different
operations internally, but it's very difficult as a user to mentally
separate those concepts.
That's why I want one switch command which does both, and is safe about
doing it.
> Instead of letting folks mentally divide subcommands into those which
> are and aren't part of daily life, are and aren't "unsafe"
Why do you keep quoting "unsafe"? It's very simple: we botched the
relocate implementation by not adding enough argument checking, and as a
result it's unsafe. If you hang around on #svn and watch for people
using relocate *for its proper purpose*, you will find that about half
the time, they wind up killing their working copy and having to re-check
it out. (Yes, we would have had to add new machinery to the working
copy to avoid botching the implementation, and yes, that might have
meant the work never got done at all. Doesn't change any of the
preceding.)
Separating common and uncommon operations into different commands is a
bizarre principle. Should non-recursive checkout be a different
command? And, of course, whether things are common or uncommon depends
entirely on how you work. People who use the same repository from home
and from work might do a relocate twice a day, just as some users might
do non-recursive checkouts all the time, even though most users never
do.
And of course, the solution to having unsafe operations is not to give
them a nice prominent command name so that people can find them easily,
but to make them safe.
> And the command count is completely unrelated to the learning curve.
Manifestly untrue. A very small amount of research would find you
testimonials from people who are intimidated by tla's 100+ subcommands.
It's a common topic of conversation on their list.
> Should we have gone the following route for the sake of making
> Subversion "easier to learn"?
> [ridiculous "svn fetch" syntaxes]
Of course not. You've added {Greg's position on command count} to
{Mike's position on switch/relocate similarity} and reached an absurd
conclusion, which you've illustrated with an equally absurd analogy.
There's an argument for combining co/update/switch into fetch, and we
discussed it long ago (as you of course remember), and we decided not to
do it *even though they do almost exactly the same thing* from an
implementation perspective. The moral is that the question of whether
two operations belong in the same command is largely independent of
implementation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 17 18:39:00 2005