Re: [Monotone-devel] non-recursive add considered harmful

[Daniel Carosone]

On Tue, Mar 13, 2007 at 10:23:25PM +0100, Markus Schiltknecht wrote:
> I fail to see how this should be more user-friendly, more secure or
> more consistent than a recursive by default behavior.

For those who missed the discussion on this subject during the summit,
let me restate that while I do have opinions and preferences with
regard to whether or not commands like 'add' should be recursive by
default, the prime directive here should be consistency.  I expect
that my personal preferences can and should be overridden in favour of
overall consistency and "harmony of user experience".

From that perspective, I can't really see that we can ever
consistently have non-recursive default behaviour.

The killer example here is 'update'; we don't and likely never will
support any kind of partial/restricted/non-recursive 'update'.
Partial update is just not meaningful, in the context of a command
that updates the base revision of a workspace[1] to reflect snapshots
of the entire tree[2].

If commands are to be consistent, they need to be consistent with a
recursive, whole-of-tree update.  Commands like commit and add can
(and do) sensibly take restrictions, but making them non-recursive
seems like a rat-hole that gets deeper by the day.

We want to be consistent, and we want to help educate users to think
in terms of snapshots and tree state as a single cohesive entity.  I
find it hard to see how that doesn't involve recursive behaviour as
the natural default, even if (through restriction arguments) some
operations are more selective about their immediate scope.

I've been hesitating to suggest it, but perhaps something to consider
here for the 'add' and similar cases is a --interactive switch, that
would operate like 'rm -i': prompting the user for 'yes/no/all/none'
as each file is processed.

If you said no to a directory, that directory and all its contents
would be skipped.  If you wanted to add the dir, but not the contents,
you could say 'yes' to the dir and 'none' for the first file inside.

It's a lazy workaround for clever shell globs or discrete commands
with explicit lists, but it's proably better than making up some weird
globlike metasyntax for "a directory but not its contents" that noone
will remember to use or quote properly for their shell.  Without being
too clever, it might significantly help user convenience and offer an
opportunity to eliminate surprises.

--
Dan.


[1] We *do* have something that is functionally equivalent to a
    partial update (pluck) but that brings in change *without*
    updating the base revision.  If the user thinks they want a
    partial update, it's probably because they're trying to do
    something they should be using pluck for, perhaps because of
    expectations carried over from CVS or elsewhere.

[2] We don't presently support partial checkout either. That's another
    rat-hole, but if we did, then update in such a workspace would
    need to carry the same restriction as the checkout and would still
    need to be recursive within that partial workspace.

pgpXCXxW_7yTb.pgp
Description: PGP signature