[Monotone-devel] restrictions - i.e. run monotone commands from within subdirectories

[Derek Scherger]

Is anyone currently thinking about or working on graydon's concept of restrictions to 
enable limiting monotone commands to a particular subdirectory of a working copy? If so 
I'd like to talk about it as I have started to look at this in some detail and currently 
have some changes that allow monotone status to limit what it reports. These should easily 
apply to other relevant commands and I hope to be back to it later today.

The concept I believe graydon has in mind is something like masking off parts of the 
working manifest so that they appear as they were in the base manifest that the current 
working copy was checked out from.

Here's a rough description of where I'm at:

Rather than strictly allowing operations from only a single sub-tree I'm working along the 
lines of being able to explicitly include or exclude various parts of the working copy. 
For anyone who's worked with the jakarta ant java build tool the approach I'm taking is 
something like the fileset concept with include/exclude specifications.

I've added two new command line options (--include= and --exclude=) that can be repeated 
as required to build up a specification of what parts of the working copy are to be masked 
off. The list of specified includes and excludes is logically preceeded by an unqualified 
 inverse of the first specifier so that something like --include=file2 would be prefixed 
with --exclude so that everything but file2 would be excluded. Using --exclude=file2 would 
be prefixed with --include so that everything but file2 would be included. Each file is 
checked against all include/exclude options in the order they are specified and the last 
value that matches determines the fate of the file. (This seems rather hard to explain but 
really isn't very complicated). If no include/exclude specifiers are present then 
everything is included by default (i.e. the current behaviour is unchanged).

Forgive my lack of sha1 has codes but suppose I have checked out the following 
manifest:

f1      file1
f2      file2
d1f3    dir1/file3
d1f4    dir1/file4
d1f5    dir1/file5
d2f6    dir2/file6
d2f7    dir2/file7

Then suppose I have made some changes so that the current working manifest might be 
something like:

f1      file1
f2x     file2           (modified)
d1f3    dir1/file3
d1f4x   dir1/file4      (modified)
d1f5    dir1/file5
d2f6x   dir2/file6      (modified)
d2f7    dir2/file7

All operations must still be done from the project root directory (where MT/ lives) but 
may be limited. For example

$ monotone --include=file2 status

would only show that file2 has changed and would ignore the changes to file4 
and file7

$ monotone --exclude=dir1 --exlcude=dir2 status

would also only show that file2 has changed

$ monotone --exclude=file2 status

would show that file4 and file6 have changed but ignore the change to file2

Currently the --include/--exclude specifications do only simple string comparisons but it 
would seem reasonable to extend them to handle regular expressions or file globs or 
something.

They do seem to apply directly to several commands (commit, update, diff, status,) and may 
apply to others (revert, merge, propagate) with some more thought. It seems that with the 
context/revision stuff the bump command's days are numbered so I haven't thought about it 
much.

The update command seems a bit strange though. If I update with some restrictions in 
place, I'll get a manifest in MT/manifest that does not exist in the database and I wonder 
if this is going to cause problems? Running monotone status after this operation would 
report "... up to date at version ..." even though this version doesn't exist in the database.

It might be good to add

$ monotone list included
$ monotone list excluded

commands to see what the restriction is going to do as well.

In terms of "jumping" up the directory structure to find the MT/ directory and files it 
contains I have not done anything with this yet. Once the --include/--exclude stuff above 
is working it should allow monotone to include only the current directory and then change 
to the root directory and perform the operation from there.

The --include/--exclude command line options are not relevant for every monotone command 
but they are always available which seems slightly bogus. What I mean by this is that

$ monotone --include=foobar --db=foo.db genkey fookey

is perfectly legal but the --include option is rather rediculous. I'm not sure whether 
this is an issue to be concerned with or not. I suppose --branch=foobar would be similarly 
 irrelevant.

I hope the current context/revision work that graydon is doing doesn't conflict with this 
too much! ;)

Cheers,
Derek