[MERGE][BUG] 51980: bzr log <file>returns inappropriate revisions

[Aaron Bentley]

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

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>> John Arbash Meinel wrote:

>>> So 'D' will not show up in either fileids_altered_by_revision_ids, nor
>>> in foo.py.kndx
>> I agree that it will not show up in foo.py.kndx.  But
>> fileids_altered_by_revision_ids looks at the delta between D and B, and
>> according to that delta, foo.py was altered.

> It will show up, but it will return C, not D. Because it looks at the
> revision="C" property, not at the current revision.

Right.  The wacky "If I ask what files were altered by D, it will tell
me that foo.py was altered by C" behavior.

You're right about fileids_altered_by_revision_ids, but I think it would
be trivial to implement the behavior I incorrectly attributed to
fileids_altered_by_revision_ids.

>>> Show C, D when C modifies 'foo'. (C did the modification, and D merged it).
>>> However, what if 'B' modified foo. Arguably then we should show B, D,
>>> since D was a merge, and relative to C it modified foo.
>> What makes B a merge?  Are you considering all parents merges?

> 
> Well, B and C were merged to create D. We have been distinguishing them
> as mainline parent, and merge parent. I was just commenting on the
> asymmetry. (It certainly can be something we are okay with, but it
> should be noted).

Well, that is our user model, so I don't think its asymmetry is a problem.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGEU1A0F+nu1YWqI0RAsKmAJ9475ju01fpr0PIQNfP3zuAqu9qswCbB4hC
b4qGEqHkffaKZAT6eUJmhJc=
=l8cd
-----END PGP SIGNATURE-----