[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] restrictions - status, diff and commit commands are
From: |
Derek Scherger |
Subject: |
Re: [Monotone-devel] restrictions - status, diff and commit commands are working |
Date: |
Mon, 05 Jul 2004 23:14:12 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040602 |
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