[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-11-02 14:17:28 CET

"Max Bowsher" <maxb@ukf.net> writes:

> 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.
> Whilst scripts are useful in the short-term, it seems very wrong that
> everyone needing these has to write/install scripts whereever they
> need these operations - there is also the problem of Windows, where
> scripting is far more difficult.
> To break the deadlock between the opposing motivations of 'keep svn
> simple', and 'add useful utilities', I'd like to propose that we
> introduce the notion of a basic and an additional command
> set. Practically, all this means is splitting commands between `svn
> --help` and `svn --help-additional`, and dividing our documentation of
> commands in the same way.
> I think this will give us a way to add less-used, but still very
> useful functionality to svn, whilst sidestepping the elevated learning
> curve which has dissuaded us from doing so in the past.
> Thoughts?

+1 on the concept.

Is there a well-defined rule that will keep us from endlessly debating
every subcommand's status from here on out (like, "the subcommand
could be written as a composition of other existing subcommands plus
some shell scripting")? Do any of the current subcommands meet your
criteria for demotion from a standard command to a "useful utility"?

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 2 14:19:37 2005

This is an archived mail posted to the Subversion Dev mailing list.