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

Re: [RFC] 'basic/additional command set' - adding svn subcommands without destroying our learning curve

From: Michael Sweet <mike_at_easysw.com>
Date: 2005-11-03 12:23:44 CET

Branko Čibej wrote:
> Max Bowsher wrote:
>> The need to keep our basic command set small, to avoid svn becoming
>> daunting to new users, and making the learning curve intolerably
>> steep, is not a new issue.
>>
>> I agree with it, but taken alone, it stops us adding useful utility
>> subcommands - the sort of thing I am thinking of:
>> svn purge: Remove unversioned files from a WC
>> svn sync: 'svn add' all unversioned files, 'svn rm' all missing files
>>
>> These are minor issues - implementable as scripts easily enough - but
>> despite being periodically requested, we've held off implementing them
>> for the reason mentioned above.
> If we decide to go with this idea, then I suggest we have *one* utility
> command. To illustrate, your examples above would become:
>
> svn util purge

Slightly off-topic, but when you do implement a "purge" command,
would it make more sense to be part of svnadmin since there is no
way to "undo" the purge?

Anyways, I like the idea of grouping "utility" commands as subcommands
under a main "util" command, but I'm slightly concerned that it could
end up as a "command junkyard". Seems like either way you go, you'll
want to define the criteria for adding new commands/subcommands to
minimize command bloat.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 3 12:24:58 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.