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

Re: Making import syntax consistant with mv, cp, export

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-10-22 22:47:17 CEST

Branko Čibej <brane@xbc.nu> writes:
> Remember so looong ago when Greg and I proposed that we just have "svn
> fetch" instead of "svn up", "svn co" and "svn switch"? Since after
> all, those commands are just variations on a common theme. We were
> overruled then, IIRC on the grounds that the different commands had
> some mnemonic value and were therefor useful.
>
> Let's decide once and for all whether we want to be complete or
> concise. If the first, "svn import" should stay. If the second, then
> very few commands remain:

Oy vey :-).

This decision does not hinge on the 'svn fetch' question. For one
thing, fetch was going to subsume commonly used commands, whereas
import is a rare command.

If people feel that `import' is a useful mnemonic, then let's keep it.
I find (for my own taste) that I could easily adjust to using 'cp' for
'import', yet still do not find 'fetch' a natural replacement for
'switch'.

I don't think there's a consistency argument here; and even if there
were, I don't think it would apply in the way you're trying to apply
it. "Consistent" is not synonymous with "natural" in interface
design. They sometimes overlap, and sometimes don't.

Can we just address the import/cp question, without philosophical
implications for the rest of Subversion? I think there don't need to
be interface-wide repercusssions from this, whichever way we go.

</end rant :-) >,
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 22 23:17:12 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.