[Monotone-devel] new restrictions syntax proposal

[Derek Scherger]

I've been playing around with an alternate syntax for specifying
restrictions lately and am curious to know what people think of the current
--include and --exclude options. 

I don't like them very much myself, for the following reasons:

     Options generally take zero or one argument rather than several
     (say the result of a file glob). So for example, to exclude all c
     files rather than --exclude *.c you need something like --exclude
     "*.c" which prevents shell globbing and the restriction matching
     then essentially needs to do it's own globbing. While I think
     allowing for regexes in the restriction syntax might be good,
     effectively disabling shell globbing seems rather bad.

     Options don't seem particlularly natural for the relevant
     commands like status, commit, etc. I would expect these commands
     to allow for a list of files that would serve as a
     restriction. So something like "monotone status *.c" would do
     what you might expect.

What I'm hoping for is that any command that accepts an argument like
FILE... could be extended so that FILE... is a simple form of
restriction and will also allow for includes and excludes to be
specified much like the current options allow. Relevant commands that
don't currently accept FILE... arguments will need fixing so that they
can be restricted.

The stuff I'm working on at the moment allows for the include/exclude
specifiers to be mixed in with FILE... lists. Since various shells
pretty much remove all hope of selecting clever operator characters
(like + and -) I've copped out and added a new lua hook
(get_restriction_ops) that returns two strings to use as the include
and exclude specifiers respectively. At the moment I have these set to
"/include" and "/exclude" although this feels somewhat DOS like and is
a bit verbose. The point of the hook is that it's easy to change them
to whatever you might like. If someone comes up with a particularly
good pair of names then we can drop the hook. The "/" prefix on the
names does seem somewhat good in that it looks like a pathname
(though, perhaps too much so) and monotone prohibits absolute
pathnames so they can't accidentally become file names.

Here's a quick run-down of the commands that I think restrictions in
this form might apply to and some questions that I have. 

nb: RESTRICTION is mandatory and [RESTRICTION] is optional.

$ monotone add RESTRICTION
$ monotone drop RESTRICTION

Both currently take a list of files or paths and I think will take a
restriction allowing for things like "monotone add *.c /exclude foo.c"
or "monotone add * /exclude MT/"

$ monotone commit [RESTRICTION]

There's currently an optional message argument to commit which might
be a bit hard to pick out from the restriction's list of files. I'm
wondering whether a --message option to replace the current argument
would be reasonable.

$ monotone update [RESTRICTION]

The current restrictions branch allows for restricted updates but I'm
not really sure if they're necessary or even sensible. It seems to fit
the pattern here and is easy enought to do.

$ monotone revert [RESTRICTION]

The current restrictions branch hasn't touched revert yet but it seems
to fit nicely as well.

$ monotone diff [RESTRICTION]

The no-arg diff case fits the pattern nicely but the one and two ID
cases have the same problem that commit does - the args are a mix of
one or two manifest ids and restriction details. Again perhaps an
option allowing one or more manifest ids to be specified would be
reasonable. Something like monotone diff --id=ID1 --id=ID2 might be
reasonable although these values may be selectors so --id might be a
bit misleading. Since --version is already taken and with the
changeset/revision stuff coming perhaps --revision=SELECTOR would be
ok.

$ monotone status [RESTRICTION]
$ monotone list unknown [RESTRICTION]
$ monotone list ignored [RESTRICTION]
$ monotone list missing [RESTRICTION]

These all fit the pattern nicely.

So rather than the --include and --exclude options that the first cut
of restrictions code has this proposal now is for two different
options (--message for commit and --id or --revision or --selector or
--something for diffs against specific versions). For --id I don't
know how the changeset branch is going to affect things but I'm
wondering whether working copy diffs against arbitrary revisions or a
diff between two arbitrary revisions will even be possible. It does
seem that --id could be used for several other commands that currently
take ID's as command line arguments and --message could be used for
monotone comment as well.

-- 
Cheers,
Derek