[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: Branko Čibej <brane_at_xbc.nu>
Date: 2002-10-22 23:01:01 CEST

Karl Fogel wrote:

>"B. W. Fitzpatrick" <fitz@red-bean.com> writes:
>
>
>>>What if we were to toss import/export and just make them special cases
>>>of copy (non-URL non-wc-path parameters).
>>>
>>>
>>I'm -1 on this. I think having an import command is an important
>>distinction.
>>
>>
>
>Why? :-)
>
>I'll tell you why I ask so suddenly. I just started working on issue
>#933, and pretty soon found all roads leading to `import' simply being
>a `cp' that works on non-versioned items.
>
>Before I go any farther, we need to figure out what we want. I'm
>beginning to think what we want is for 'svn cp' to Do The Right Thing
>when copying non-versioned data to a URL dest.
>
>

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:

    svn cp (copy, import, export, move)
    svn fetch (checkout, update, switch)
    svn commit -- or is that just another instance of "svn cp"?
    svn patch (diff, merge, patch)

and, of course, the working-copy stuff, propsets and other little details.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
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:01:43 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.