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.
pgpQXshIXUaKa.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel