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

[Vincent Ladeuil]

>>>>> "Ian" == Ian Clatworthy <ian.clatworthy at internode.on.net> writes:

    Ian> This patch fixes log so that the end revision is used
    Ian> for mapping a FILE to a file-id. This means log can
    Ian> now find deleted files. It also means renamed files
    Ian> are matched against their name at the time.

This will help many users.

Yet, it's still incomplete.

Imagine the following scenario:

1. add file 'foo' (got file-id 'toto')

2. renamed it 'bar'

3. rename it 'baz'

4. delete it

I argue that for such scenarios you really want the ability to
use file ids.

bzr log  baz => doesn't work
bzr log -r1.. foo => doesn't work (though I think you make it work in a later patch)
bzr log -r2..3 baz (err, wait, is it bar ?)

bzr log bar => doesn't work (too bad, that's the only name I'm sure about)

Or you will keep trying various ranges until you find the right
path to use for the 'bzr log' command and even then you may not
be able to display all the revisions you're interested in.

Whereas if you can find the file id you can then use it to
display all related revisions.

I agree that we should *avoid* *requiring* using internal ids,
but that doesn't mean we have to make user's life miserable just
because we don't *allow* it.

I use revids daily. I don't like them much, but it's often the
most effective way.

bzr log --file-id toto => Works !
bzr log -r2..4 --file-id toto => Works !

   Vincent