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

[John Arbash Meinel]

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

Kent Gibson wrote:
> 
> 
> Kent Gibson wrote:
>>> I tried something like that originally. It was better than the
>>> deltas approach, but no where near as fast Robey's approach -
>>> fileids_altered_by_revision_ids is sufficiently slow that it has a
>>> progress bar. And the output was the same, at least for the
>>> examples I checked at the time. No merge commits in either.
>>>
>>> Worryingly, I just compared the output of the two approaches on
>>> NEWS and the fileids_altered_by_revision_ids approach returned a
>>> few revisions LESS. Note sure if that means the patch returns
>>> incorrect revisions, or fileids_altered_by_revision_ids is missing
>>> some. More investigation required, but at least one of them is sure
>>> to be wrong, if not both.
>>>
> I've dug a little deeper on this.
> The get_weave approach returns some extra revisions compared to the
> fileids_altered_by_revision_ids approach:
> 
> lalo at exoweb.net-20050914052213-2aa5c1005959abdf
> lalo at exoweb.net-20050915151611-86c5de4298bb71f9
> robertc at robertcollins.net-20050919044328-0205c679f3051340
> robertc at robertcollins.net-20050912143501-941cc76acb5be086
> aaron.bentley at utoronto.ca-20050918214753-129f45a74b8af9f2
> abentley at panoramicfeedback.com-20050914165444-335a16dc80f7c129
> mbp at sourcefrog.net-20050912082124-c6b174bd5d971cc0
> robertc at robertcollins.net-20050914172314-4c220f175bb62fe0
> robertc at robertcollins.net-20050912123958-7982e808f291f439
> mbp at sourcefrog.net-20050916033244-18c4f4bcba663e42
> robertc at robertcollins.net-20050919060519-f582f62146b0b458
> john at arbash-meinel.com-20050918014804-c652edd3718c6498
> aaron.bentley at utoronto.ca-20050919023309-24e8871f7f8b31cf
> robertc at robertcollins.net-20050914151159-2986150cde2d744a
> lalo at exoweb.net-20050913095212-210555d61a893f1e
> 
> They appear to be merges or commits that do not directly change NEWS,
> so the get_weave is returning spurious entries. e.g.
> abentley at panoramicfeedback.com-20050914165444-335a16dc80f7c129 is just
> a change to commands.py.
> The interesting thing is that they are all from the same time frame -
> mid Sept 2005.
> Could it be there is something amiss with revisions from that time?
> 
> I'm happy to pursue this, but Sept 2005 is well before I met bzr, and
> my knowledge of weaves is near zero, so if anyone can shed some light
> it would be appreciated.
> 
> Cheers,
> Kent.


My best guess is that if 2 sides of a branch modify the same file, then
'get_weave' will return the revision which merges them together. For
example:

A - B - C - D
  \       /
    E - F

If B and F modify NEWS, then D will also get marked. This is because it
is resolving the changes from both branches.

It may not directly modify anything, but it is altering meta
information, so it gets an update.

I would also imagine that if you checked the InventoryEntry for
abentley at panoramicfeedback.com-20050914165444-335a16dc80f7c129 you would
find that the entry for NEWS has a new .revision (last changed revision
marker). Because that is for meta-information as well as textual
information.

I could be wrong, though. Because if that was the case, I would expect
fileids_altered_by_revision_ids to reflect it....


The other possibility is that this is a fairly old revision (2005-09),
so the change detection algorithm might have included more than it should.

It is probably something to look into (next week).

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

iD8DBQFF+/5zJdeBCYSNAAMRAr1UAKDSnIlbI8xnd4SWAmnolkW+BwJi5QCfbKtw
wXddDBO4zSGHjWCjEgFT2Xo=
=zhRB
-----END PGP SIGNATURE-----