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

[John Arbash Meinel]

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

John Szakmeister wrote:
> 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?

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

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

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

John
=:->


> 
> Thanks!
> 
> -John
> 

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

iEYEARECAAYFAktIfU0ACgkQJdeBCYSNAANi5gCfZ1uhHJ/Whdlbx3TWI6Af+uME
2y8Ani2FPI7pbz9zWsTXOGLyvliXcFA7
=TzFp
-----END PGP SIGNATURE-----