Better name for dpush wanted

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
> Aaron Bentley wrote:
>> Ian Clatworthy wrote:
>> I don't like this idea at all.  You wind up turning one command into
>> several commands with no clear usage statement, because it varies
>> according to what "actual" command you're doing.  You get boatloads of
>> options that can only be used when particular other "options" (that are
>> really subcommands) are used.
> 
> That's possible but not necessarily true. The flip-side to having
> multiple commands is that you can end up struggling to find the command
> you want and, in some cases, a large number of options get repeated
> across commands.

I'm not saying every possible operation should have its own command.  We
should use judgement, just as we always have.  I don't agree that "one
concept, one command" is a good input to that judgement.

> Or they ought do. Take log and missing for example: now
> that log is much more powerful, users want most of those new options
> available on missing.

I agree that it can be hard to decide where functionality should go.  I
struggled a lot with "merge --preview", for example.

>> We have this already with shelve --list, and I hate, hate, hate it.
>> What does "shelve --list --destroy" mean?
> 
> Not much. But neither does "upgrade --1.6 --1.9".

We've specified that it means "upgrade --1.9".

> Sounds to me like
> --list and --destroy are values of a registry option called something
> like 'action'.

I don't see --destroy as an action value.  It's an optional behaviour of
shelve, just as --all is.  The problem is --list.  It *is* an action
value-- it turns the shelve command into a different command that
doesn't use any of the normal shelve options.  I could as easily have
said "What does 'shelve --list --plain' mean?" or "What does 'shelve
- --list -r 5' mean?".

'action' should never be a command option.  (I know it is in
reconfigure; see below)  If we're going to do subcommands, we should do
them properly; "shelf list", not "shelve --list".  That way, at least
the help can be clearer about which options apply where.

We don't have the infrastructure for this at present, and I don't see a
lot of difference between "shelf list" and "shelf-list".  I think that
shelf-list is more discoverable than shelf --list or shelf list, but it
wouldn't hurt to have a "shelf" help topic to describe how shelve,
unshelve and shelf ls fit together.  Remember that all bazaar commands
are subcommands of "bzr", so these would be sub-sub commands.

> To me, "one concept, one command" implies something like:
> 
> * shelve = put things on a shelf
> * unshelve = take things off a shelf
> * ??? = view/manage things on the shelves
> 
> I don't think ??? ought to be called 'ls-shelf' either because then
> adding management features to that command would feel wrong.

I disagree that ??? makes sense.  I think management features that don't
 fit on our existing commands should have their own command.  That's why
I think ls-shelf does make sense.

One of the reasons I did not propose a shelf command is that I had
carefully looked at the original shelf command, and either moved its
functionality to options on shelve/unshelve or decided it wasn't needed
at all.  Except, of course, for ls.

> (Right now, tags only lists the tags but I'm planning to add a --clean
> option to clean out crap tags. It could also take a list of tag names to
> only list/clean those tags.)

"clean" is a concept, right?  Shouldn't we have "clean --tree" and
"clean --tags"?

>> I also don't see how "one concept, one command" applies to turning
>> init-repo into init --repo.  To me, they're not the same concept at all.
> 
> Initialisation is one concept - it ought to be one command.

Outside of bzr, initialization is accomplished in many ways-- touch,
mkdir, ln, running a Word Processor, opening your file manager and
selecting "create document".  I don't think users have an expectation
that initialization of different types of things should be done the same
way.

init-repo's --no-trees option only makes sense on shared repositories.
init's --append-revisions-only option only makes sense on branches.  If
you unify the command, you have to treat --repo invocations as a
separate operation in the help, and probably also in the implementation.
 Yet all the help will be jammed together.  This is a mess.

You might as well argue that commit, push, pull and update all modify a
repository, so they should all be a "modify" command.

> Compare
> info, upgrade & reconfigure.

Reconfigure, btw, should also be a host of commands or a command with
subcommands.  So far, it's not too painful, but the --bind-to option
only makes sense when --checkout or --lightweight-checkout is specified.

> This will become more important when what
> we want to initialise is not just a branch nor a repo, but a combination
> of the two (e.g. colocated branches).

Maybe it would be better to start with that.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn4bRIACgkQ0F+nu1YWqI1vrQCeOsXjdBN3ZFp/awcoX+VtRxYq
RXYAnjLfU5LrjyVjBMTpxIxsfPz4VLRe
=t8k6
-----END PGP SIGNATURE-----