log and annotate should work on removed files

[Sven Sandberg]

When a file has been removed from the repository, it is very difficult to find out what revision it was removed. The only way I know is parsing 'bzr log -v', which is difficult for the user and a very slow operation (for MySQL, it's too slow to be practical). It would really be useful if it was possible to:
 - Get the revision in which the file was removed. I can't think of any better way than to invent a new command, but whatever way you find best is acceptable.
 - Use 'bzr log FILE' if FILE is removed.
 - Use 'bzr annotate -r <revision where file existed> FILE'.
 - If FILE is removed in REV, 'bzr annotate -r X FILE' should print 'file was removed in revision Y' instead of 'FILE is not versioned'.

[John A Meinel (jameinel)]

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.

[Ian Clatworthy (ian-clatworthy)]

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.

[Andrew Bennetts (spiv)]

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.