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

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

...

>> 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?

C is the ghost, time goes downwards (D was committed after merging C).

>   * 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.)


John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktL+2oACgkQJdeBCYSNAAPV/gCg1WMUZQII+3GNnGD/nCBUmUtN
hjcAn1nBYVvagOx4VvJ34ZnAuOMbY0f8
=bB+n
-----END PGP SIGNATURE-----