[MERGE][RFC][1.11] implement `missing --revision 3..4 --other-revision 3..4`

[Ian Clatworthy]

Marius Kruger wrote:
> Hi,
> 
> This implements `missing --revision 3..4 --other-revision 3..4`
> and `missing -r 3..4 -o 3..4`.

I'm 95% happy with this but it probably needs a little more discussion
but I can vote tweak.

bb:comment

> Aaron mentioned in the `bzr pull --dry-run` thread
> (
> http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/50716 )
> that we can may want the following syntax:
> missing -r [REMOTE REVISION]..[LOCAL REVISION]

My concern with this is that "missing" is arguably symmetrical,
unlike pull and push (say) where the revisionspec obviously
refers to the "from" branch. Some users run missing before pulling,
others before pushing, others before merge/update/whatever.
With the above UI, my concern is that I'd always be forgetting
which argument (1st or 2nd) was the remote vs local one.

> Maybe there is not a lot of use cases for specifying the minimum versions,
> so we can maybe drop it, or put that functionality in a obscure option.
> above could be:
> missing -r [REMOTE REVISION]..[LOCAL REVISION] --min-revision [REMOTE
> MIN REVISION]..[LOCAL MIN REVISION]

As explained above, I find separate options for their-revision vs
my-revision more obvious. Your option names are fine though I'm
a little uncomfortable with -o as it means "output-file" in a fair
number of commands. (We might one-day want that is missing as the
output can be large.)

I also suspect that filtering on remote revisions will be more
common than on local, because pulling/merging/updating arguably
happens more frequently that pushing, especially given Bazaar's
bound branch support. So my suggestion is:

* --revision, -r for remote revision filtering
* --my-revision for this revision filtering.

I don't think the latter needs a shortcut.

Beyond the UI design debate, here are some tweaks ...

Please add a NEWS entry.

Please expand the missing help to include filtering examples.

> +        # clone and add a differing revision
> +        b_tree = a_tree.bzrdir.sprout('b').open_workingtree()
> +
> +        for i in range(2, 6):

s/a differing revision/differing revisions/

> +        out,err = self.run_bzr('missing ../b -r 2', retcode=1)
> +        self.assertMessages(out, ('a2', 'b2', 'b3', 'b4', 'b5'), ('a3',))

So if just one limit is given, it's implicitly an upper one?
I had expected it to be the lower one with the upper limit being
the last in that branch. (If I'm right, there's a bug, right?)

> +
> +        self.assertUnmerged([], [('4', 'rev6', 0)],
> +            tree.branch, tree2.branch, 'all',
> +            include_merges=True, remote_revid_range=(rev6, rev6))

You could probably drop the 'all' parameter as you've done
elsewhere.

> +        self.assertUnmerged([], [('3', 'rev3',0 ), ('3.1.1', 'rev4', 1)],

add space after ,.

> +        self.assertUnmerged([], [('4', 'rev6', 0),('3.1.2', 'rev5', 1)],

Ditto.

Ian C.