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

I think that's because we'd have to find a way to introduce those
revisions somewhere, and I'm not sure on the mainline makes sense.
Jelmer does have a flag in there to make bzr-svn create a branch and
push the revisions up... but the last time I tried that, it didn't
seem to be doing something correctly (I think some bit of information
wasn't being set, so it failed to find the revisions anyways).  If I
always push the revisions into a branch myself, and then merge them,
it's not an issue.  The problem is I can't guarantee that all folks
are going to do that.  And we already have a case where this has
occurred (admittedly, before we knew anything at all about ghost
revisions).

[snip]
> 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

Okay.  I just wanted to make sure I'm understanding the issue before I
invest much time in to fix it and heading down the wrong path. :-)

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

Agreed. :-)  Thanks for the explanation John!  I found it very helpful.

-John