log and annotate should work on removed files

At the moment, we work in only 'tree snapshots', which means that when a file is deleted, it "just disappears" and we don't record the *delta* of it having been deleted.

This is certainly a limitation of how we are recording information. Though there are a few possibilities...

1) 'bzr log -v' uses a tree comparison between revisions (so looks at the delta, rather than the snapshot). We have a few ideas as to how to make that faster (split-up inventories, recursive hashes, journaled inventories)

2) Consider how to record something that is only a delta (delete) as part of a snapshot. Journaled Inventories might be a way to go about it.

It is certainly a limitation that we run into from time to time.

I made some changes to log some time back to enable it to "see" deleted files. The trick is to give a revision range such that the file exists at the start of it. From the help ...

"Filenames are interpreted within their historical context. To log a deleted file, specify a revision range so that the file existed at the end or start of the range."

I believe using -v will show exactly when the file is deleted.

Bug 551758's original description has a minor variation on this: 'bzr annotate -rX FILE' fails when FILE in the working tree didn't exist in revision X, even though another file with the same filename did.

As I commented there, I think: annotate could/should notice that a file with the same path exists, and assume you meant that instead (and emit a warning about the possible confusion). I can't think of a situation where this would be less desirable than the current behaviour, but we could add a --strict or something if necessary.