[MERGE][#175520] use historical context for file logging

[Ian Clatworthy]

Adrian Wilkins wrote:
>> If we start supporting file-ids in the UI, I'd like to do so
>> across every command and allow you to specify "fileid:..."
>> anywhere you can currently specify a file.
> 
> +1 on supporting file-id ; when the FAQ of "how do I find the revision a
> file got deleted in" came up for the Nth time in IRC, my first impulse
> was to implement a --file-id option for `bzr log` which is relatively
> easy since it just resolves them internally anyway.

FWIW, if this patch and my faster-log patch land, log will begin showing
revisions that deleted a file *provided* one specifies a lower revision
limit of some kind and excludes the merge revisions. The latter can be
achieve via --short, --line or the proposed --no-include-merges option
(yet another log patch). So there will be an workaround of a kind until
the problem is addressed via a later format.

Technically, my faster-log patch makes a choice wrt file-matching
algorithm: per-file graph (current) or delta-lookup. The latter is
currently more accurate and faster at incrementally showing results.
However, it is unacceptably slow across a large number of revisions,
(ala log -v now) so unfortunately it can't be the default until the
split-inventory format lands. I guess we could be smarter still and
use a combination: delta until the delete is found then per-file graph?
Our time may be better spent elsewhere though, e.g. getting split
inventory landed.

> Of course, because of the way inventories are stored, it doesn't make
> this operation any cheaper or much easier. Does split inventories fix
> this - is it cheaper to determine where a file was deleted because the
> deletion is marked by a "deleted" delta instead of "poof! it's not in
> this revision anymore"?

I'm not sure sorry. I expect split inventories to make delta lookup
much faster at least but I'm not sure if it enhances the per-file graph
information as well. John? Robert?

Ian C.