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

[John Arbash Meinel]

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


...

>> The issue is that bzr-svn is preserving the last-modified information
>> from the ghost that it isn't including in the ancestry. bzr itself, and
>> other converters don't ever do that.
> 
> I'm not sure how to interpret that: is bzr-svn doing something wrong
> then?  Or are you saying it's just different?
> 
> -John
> 

So bzr-svn is currently the only path that actually knows about a
revision, but introduces a ghost anyway. It does this when pushing from
bzr => svn and not having it include merge revisions.

I don't know that it is specifically wrong, but it certainly is a
somewhat unexpected case. Most of the code assumes that if you knew
about X then you would transmit it.

(In all other cases, if we have a ghost, we don't know its contents, so
we can't assign last-modified-revision, etc to that ghost revision.)

I think it is mostly about polishing the rough edges and handling the
unexpected cases.

For example, 'diff' wants to generate a modified time for a file. We
currently check the timestamp on the commit. However, if the
last-modified revision is a ghost, what time do you put? Do you do the
epoch? Do you try to search for another revision that is 'close' and use
that timestamp? etc

Right now we just fail, which is obviously one of the worst of the
possibilities.

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

iEYEARECAAYFAks7dCEACgkQJdeBCYSNAAOd5gCfRHswuOA+1FSG8RD/iJmM/Gsp
+nsAnRlMB2YlKEU1zE0090lsz7YEdm60
=ud/o
-----END PGP SIGNATURE-----