Re: [Monotone-devel] revert --missing misbehaves in 0.26

[Derek Scherger]

Derek Scherger wrote:
> 1. I think that 'revert --missing' currently has different behaviour 
> than  'drop --missing' and 'add --unknown' and I'm curious as to what 
> people's expectations are. What 'revert --missing' does when it has a 
> restriction (i.e. 'revert --missing path ...') is essentially to run 'ls 
> missing path ...' and then revert the missing paths that match the 
> restriction. The restriction applies to missing things. Conversely, 'add 
> --unknown path ...' and 'drop --missing ...'  add or drop *all* missing 
> paths in *addition* to those that match the restriction. So in revert's 
> case, the --missing set is intersected with the restricted set. While in 
> the add/drop cases the --missing set is unioned with the restricted set. 
> I haven't checked but it would probably be good if someone can confirm 
> this actually is the current behaviour. The question I have is, is this 
> behaviour "correct" or perhaps intuitive?

Ok, I've now checked and I'm wrong here, revert --missing, drop 
--missing  and add --unknown all work the same as far as restrictions 
are concerned. They first effectively run the corresponding ls command 
with the specified restriction and then operate on the resulting set of 
paths.

One small problem though, 'mtn ls unknown foo' and 'mtn add --unknown 
foo' both fail if foo is an unknown path. The current restrictions code 
doesn't let you specify restrictions based on paths that unknown known. 
It does unknown paths that are also ignored  to be specified though.

If I recall correctly, this behaviour was added to fix problems like 
'mtn commit foo' from doing a whole-tree commit, rather than failing if 
foo is unknown. The issue at the time was that unknown paths were simply 
removed from the restriction which ended up empty and allowed everything 
through. I don't think this is possible any more but I need to check 
further. This is dredging up some rather foggy memories!

Cheers,
Derek