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

[John Szakmeister]

On Sat, Jan 9, 2010 at 7:57 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
[snip]
>> So does that mean a ghost generated some other way is a no-op?  Does
>> it change mainline content somehow?  I'm not sure what a ghost is in
>> this case.  I would think that the result of whatever generated the
>> ghost is represented somehow... you just don't have the details of how
>> it came to be.  Is that the correct way to think about a ghost
>> revision?
>
> The other converters (such as the Arch converter) could see that there
> was a parent (foo at bar--archive--patch-20) but did not have access to it
> (it was in a separate repo which is no longer available). The idea
> behind ghosts was that we could mark "and there is some ancestry here",
> such that if someone *else* had access to the repo and did the
> conversion, then when we merged from them, it would fill in our gaps.
>
> In bzr-svn, when it pushes from a bzr repo to an svn one, it throws away
> the bzr merge history that it cannot represent in the svn repo. However,
> it does transfer the last-modified-revision information for individual
> files. So in the graph:
>
> A
> |\
> B C # C modifies 'foo'
> |/
> D   # D just brings in the changes from C
>
> Pushing that to SVN will leave you with
>
> A
> |
> B ? # Something named C
> |/
> D   # foo in D still claims that it was modified in C
>
>
> None of the other converters can do that, because they didn't have
> *access* to C to know that foo was modified there. They all just mark D
> as the last-modified revision. (foo is different in D than in all
> available parents.)

Right, I get that part: bzr-svn has access to that information, but it
can't put those revisions into the repo.  However, it still leaves the
inventories marked up pointing to revisions that don't exist.

Maybe I should ask the questions differently:
  * In your graph above, D is the ghost revision, right?
  * 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?

[snip]
> Because the inventory for "D" says that "foo" was modified in another
> revision.
>
> (This is one of the problems with a deterministic converter, that is
> expected to map 1:1 between systems that don't completely map 1:1...)

So, the right answer here is... not to lookup those revisions when the
parent is a ghost?  Or maybe, not to treat them as an error when the
revision isn't present?

I apologize for all the questions, but the backend is quite
complicated and I'd really like to see this problem solved.

Thanks!

-John