Re: [Monotone-devel] restrictions - status, diff and commit commands are working

[Derek Scherger]

Here's where I'm at with the work on restrictions I started last weekend and a few 
questions that I currently have for anyone who's interested.

I haven't yet committed anything to my database and I'm wondering whether people might 
prefer to see this on the net.venge.monotone branch or on a new 
net.venge.monotone.restrictions branch if/when they pull it from me. The changes I have so 
far are not really all that invasive and the current behaviour is preserved so either way 
is fine with me.

The following commands are doing restricted operations using the --include/--exclude 
options that I tried to describe previously. I'm not really liking this syntax much though.

$ monotone status --include foo/ --exclude foo/bar

shows the status of the current working copy, restricted to the directory foo/ but 
excluding any files or directories in foo/ that start with bar.

$ monotone diff --include foo/ --exclude foo/bar

shows the current working copy diff, subject to the same restriction. currently this works 
for the no-arg and one-arg diffs which compare the current working copy to some other 
database manifest. the two-arg diff that compares two arbitrary database manifests has not 
been done.

$ monotone commit --include foo/ --exclude foo/bar

commits the current working changes, subject to the same restriction. the MT/work file is 
rewritten so that committed changes are no longer listed and uncommitted changes remain 
for future operations.

$ monotone ls unknown --include foo/ --exclude foo/bar
$ monotone ls ignored --include foo/ --exclude foo/bar
$ monotone ls missing --include foo/ --exclude foo/bar

lists unknown/ignored/missing files that exist in the directory foo/ but excluding any 
files or directories in foo/ that start with bar.

The following commands are not yet doing restricted operations but have prompted some 
questions.

$ monotone revert
$ monotone revert file ...

these seem to fit the mold above quite nicely but the --include/--exclude syntax is really 
not very nice. I'd like a better way of specifying things that still allows for a mix of 
includes and excludes so that large chunks of the working copy can be included or excluded 
easily. Presumably a simple list of files (i.e. *.cc) should suffice as a list of things 
to include with everything else excluded.

I've wondered about something like ~file (or ~prefix) to exclude a specific file or bunch 
of files with a common prefix. Also !file, etc. but this wouldn't be very nice for 
excluding a globbed list of files. Perhaps ! or ~ or - should invert the current 
include/exclude context allowing for something like:

$ monotone status *.c ~ foo* ~ bar*

to include all .c files in the current directory, exclude foo* and include bar*. Perhaps 
using + and - would be good, with an implicit + at the front of the list?

$ monotone status *.c - foo* + bar*

Hmm... I kinda like that.

$ monotone update

Presumably a restricted update should merge in only some changes from the database, such 
as those within some particular subdirectory of the working copy. Given a working copy 
based on some manifest, update currently attempts to choose a new manifest to update to 
and then merges these changes into the working copy so that the working copy is then based 
on the chosen manifest.

It seems that in this case the restriction applies to the chosen manifest, in that only 
some of the changes between the original base manifest and the new chosen manifest should 
be merged in to the working copy. Would it be a problem if a working copy ends up based on 
a manifest that does not exist in the database? i.e. monotone status may report something 
like "...up to date at version f45e3..." even though this version never appears in the 
database. I don't think this should cause any problems but...

At the moment restricting the changes visible in a working copy seems somewhat easier than 
restricting changes between two arbitrary manifests since the working copy has some 
information about adds/dels/renames in the MT/work file. Given two arbitrary manifests 
this information needs to be created and this is currently done inside 
manifests_to_patch_set in a way that doesn't make it easily available. I'm wondering if 
the context/revision stuff might help sort this out given that each revision will contain 
information about adds/dels/renames making the changes between two related manifests much 
more apparent. If the manifests are not related in terms of ancestry then the information 
might still not be available though. This is my current problem with both update and the 
two-arg diff case.

In terms of jumping up the tree to find the MT directory from which to operate I haven't 
done anything yet. All of the above commands must still be run from the working copy root 
(where MT lives). This seems like it should be relatively easy to do once the restrictions 
are sorted out. The list of restrictions will need to be prefixed with an include for the 
current working directory and any additional restrictions will need to have this prefix 
added. I'm expecting that the operation would still be done from the root of the working 
copy after changing to that directory internally.

Questions/answers/comments/feedback appreciated.

Cheers,
Derek