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

[John Szakmeister]

On Wed, Dec 30, 2009 at 10:39 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
[snip]
> 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.

Sorry for bringing this up again, but I had a few more questions regarding this.

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

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?

> 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

But the resultant merge has a time-stamp, right?  The actual merge
commit isn't a ghost, right?  It should be real, and has real data.
Why can't that information come from there instead (realizing that it
may not be 100% correct)?

I still feel like I'm missing something here.

Thanks!

-John