Comment 3 for bug 268989

So there is a question as to what is the "right" fix

1) Always sort deletes before renames?
2) Check to see if a file is going to be put in the place, and ensure the sort order "on-the-fly" ?

The problem with the former, is that it will tend to group like "status" does, and give you:

=== deleted A
=== deleted B
....
=== renamed C => A

And the deleted section will be far away from the renamed section.

I *think* we sort by path, but I'm not sure how we handle ties. In this case, there are 2 paths at the same possible location, so we might be sorting by file_id.

Anyway, whatever fix, we should also check that switching:
bzr rm foo
bzr mv bar foo

for
bzr rm bar
bzr mv foo bar

has the same fix.

At present, doing that gives:
=== removed file 'bar'
--- bar 2008-09-11 21:35:10 +0000
+++ bar 1970-01-01 00:00:00 +0000
@@ -1,1 +0,0 @@
-bar

=== renamed file 'foo' => 'bar'

Which seems to be what you are asking for in the "bar => foo" case.