non-chronological rearranged revision numbers: bug in churn, or base mercurial?

[Haszlakiewicz, Eric]

I am using Mercurial 1.8.2.

I have a repository that now looks a bit like this, in terms of revisions numbers and structure:

R1--->R2----------------R5(TagA)--->-R6(merge)--->R7(TagB)
       \----->R3-->R4---------------/

I'm trying to use the churn extension to show a count of lines that changed between TagA and TagB:

hg --config extensions.churn= churn -r TagA:TagB

But it's only showing a count of the changes made in R7.

hg diff -rTagA:TagB

I'm guessing that the structure of the repository of confusing it.  Although the R6 has a larger revision number, it actually happened earlier, chronologically speaking, than R3.  For some reason mercurial decided to rearrange the revision numbers to this more confusing order.

In my real repository there are actually many more tags and merges, which used to show up nicely as:

R1--->R2------>R3---->R4--->R6--------------->R9-->R10----etc...
      \                 \                            \
       \---R5------------\---->R7(merge)->R8----------\R11(merge)->R8

but instead I now get a horrible nest of a dozen parallel apparent "branches", with all the merges looking like they're the most recent things that happened.  
I've tried re-cloning the repository, with and without --pull, but it doesn't make a difference.

So, I have three questions:
  1) Is it a bug in churn that it can't handle this?
  2) Is the fact that the revision numbers aren't even vaguely chronological a bug?
  3) Is there a way to force mercurial to renumber the changesets in a better order?

eric