[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] restrictions
From: |
Derek Scherger |
Subject: |
[Monotone-devel] restrictions |
Date: |
Tue, 20 Jul 2004 22:49:08 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040602 |
The initial cut of the restrictions stuff I've been playing around with is available via
netsync at www.echologic.com on the net.venge.monotone.restrictions branch for anyone who
might be interested.
I've modified the status, diff, commit, update and ls unknown/ignored/missing commands to
use the restriction as specified by any --include and --exclude options. The argument to
these options is a path prefix and if it matches a path in the manifest then that file is
included or excluded for the current operation depending on which option it is associated
with. Without any --include/--exclude options these commands all continue to function
normally.
Each path is checked against all include/exclude options in the order they appear on the
command line and the last matching status is taken. The list of options is logically
prefixed by the inverse of the first option so that --include foo first excludes
everything and then includes paths that start with foo and --exclude foo first includes
everything and then excludes paths that start with foo.
Because of the way this currently works, less selective options should probably be
specified before more selective options. i.e. --include foo --exclude foobar would include
any paths starting with foo except for those that start with foobar whereas --include
foobar --exclude foo would exclude everything.
This syntax has lots of shortcomings and I'm not at all happy with it so it will almost
certainly change. For starters, a good syntax should simply accept a list of files to be
included so that monotone status files, monotone diff files, monotone commit files all do
what would be expected. Of course "files" would often be something like *.c which gets
expanded by most (all?) shells before being passed in as args. I think a good syntax
should also allow for including and excluding sets of files and the previous case is
simply one where the specified files are included and all others are excluded. I've been
wondering about some way of specifying a set arithmetic type of expression to describe
what should be included and excluded. i.e.
monotone status *.c # as a shorthand for monotone status + *.c below
monotone status + *.c # start with an empty set of changes and then include
.c files
monotone status - *.c # start with the complete set of changes and then
remove .c files
monotone status *.c - foo.c # include all .c files except foo.c
I haven't thought through the semantics of this very carefully so there may be problems
with it. I know people are somewhat worried about using - because it often has other
meanings and I don't know what popt might do with it. I'm open to suggestions...
Restricted update is a little strange in that it only merges some of the available changes
into the working copy and what this does is leave the working copy based on a manifest
that quite likely doesn't exist in the database. The first problem this seems to cause is
that committing such a working copy creates a manifest with no ancestor and if/when this
is merged it will use the 2-way merge algorithm. I'm not sure if this is a big issue or not.
There is nothing yet that goes jumping up the working copy tree to find the MT directory
so all commands must still be run from the top of the working copy.
The calculation of restrictions is based internally on monotone's patch_set structure
which I know is going to get worked over by the changeset stuff that's coming. Hopefully
something similar will still exist and converting over to the new structure won't be too
difficult.
It seems that it might be possible to allow restrictions for merge and propagate too but
I've left these for now. Partly because I don't know what all of the implications might be
and partly because I'd like to improve the syntax and see about working from within
subdirectories of a working copy.
--
Cheers,
Derek
[pubkey address@hidden
MIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQDACq6E1Dm1CXq7czaZo4/ycKgqQShewclx
HAcweq0imG/NucgdDgsw/3ZIOq+IVwXya+Axqst3sHz5km8s94XvBcgjzHF1jyeGiN9UEBSN
R+ecT8rF5ogC6OsBpgTMHYASpcuGimLsupz1HE7bz/2o95hIdb6NaV4Ni2FYy/VoiwIBEQ==
[end]