'bzr blame' fails with ghost revisions and 'bzr check' output...

[John Szakmeister]

On Mon, Jan 11, 2010 at 11:32 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
[snip]
>> Maybe I should ask the questions differently:
>>   * In your graph above, D is the ghost revision, right?
>
> C is the ghost, time goes downwards (D was committed after merging C).

Doh.  Of course.

>>   * Is the fact that D refers to C okay?  'bzr check' gives tells me
>> the parent is inconsistent.
>>   * Should 'bzr check' somehow get taught to treat the fact that D
>> refers to C is okay?
>>
>
> I would like to understand why it thinks there is an inconsistency. In
> new formats both the revision graph and the revision should claim "B, C"
> as the parents of D. Even though C isn't present. (knit formats could
> not represent a not-present 'C' parent.)

In my case, the graph looks more like:
A
|\
| B
| |
| C
| |
| D
|/
E

So the parents for E is both A and D.  But in the inventory (I
assume), it knows that C is a (text) parent of D.  It's complaining
about the fact that C is missing.  Does that make sense?

-John