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

[Kent Gibson]

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



John Arbash Meinel wrote:
>>
>> Any luck with that?
>
> Actually, yeah. I factored out the important function you had into a
> separate function that could be tested.
>
> The branch is available from:
> https://code.launchpad.net/~jameinel/bzr/log-ancestry
>
> or
> http://bzr.arbash-meinel.com/branches/bzr/0.16-dev/log_ancestry/
>
> in case LP hasn't updated yet.
>
> One thing I was hoping for is to be able to not generate a set() for
> every revision in the ancestry. Since often the set will not change
> (since it is only updated when new entries are added, or there is a merge).
>
>
> I was also hoping to improve not having to extract the revision graph 2
> times, and have it 'tsort' in one place and 'merge_sort' in the other.
>
> tsort is faster than 'merge_sort' because it has less sorting to do.
> However, if we already need a merge_sort, we might as well use it.
>
That one I had noticed - I was going to tidy it up later, but I didn't
think getting the revision graph took a significant amount of time (it
was already being done once and seemed negligible compared to
everything else).

> I did find one big performance improvement, which is to not generate a
> new set for every revision. If nothing has changed, you can just use a
> reference to the existing parent set(). It dropped "bzr log NEWS" from
> 22s => 8s for me.
>
Nice.
> That is enough for me to want to merge this now, since it seems to be
> universally faster than the existing "bzr log foo" and it is
> significantly more correct.
>
Yay.
>> Cheers,
>> Kent.
>
> We'll see if we can get a review in for 0.16.
>
> One very interesting thing about this change, though. Is that if you
> have a revision which makes a change, and then another revision which
> reverts that change, you still end up showing that file as "modified" by
> the top-most revision.
>
> Specifically, I'm seeing this:
>
> $ ./bzr log bzr
>  2362 Kent Gibson       2007-04-11
>       merge bzr.dev
>
> However a '--verbose' doesn't show bzr as modified.
>
> It turns out the the merge has a rather involved ancestry:
> ------------------------------------------------------------
> revno: 2362
>   merge bzr.dev
>     ------------------------------------------------------------
>     revno: 2359.1.9
>       Update NEWS to match bzr 0.15.
>         ------------------------------------------------------------
> **      revno: 2323.2.3
>           Merge Martins 0.15rc2 release branch.
>             ------------------------------------------------------------
>             revno: 2358.2.1
>               prepare to release 0.15rc2
>         ------------------------------------------------------------
>         revno: 2359.1.8.1.1
>           Update NEWS to match bzr 0.15.
>         ------------------------------------------------------------
>         revno: 2334.1.5
>           [merge] bzr.dev 2371
>         ------------------------------------------------------------
>         revno: 1551.2.49.1.40.1.22.1.42.1.31.1.39.1.4
>           Merge bzr.dev
>         ------------------------------------------------------------
>         revno: 1551.2.49.1.40.1.22.1.42.1.31.1.21.1.54.1.12
>           Merge bzr.dev
>     ------------------------------------------------------------
>     revno: 2359.1.31
>       merge 0.15 back to dev
>         ------------------------------------------------------------
>         revno: 2323.2.3.1.2
>           (mbp) various integrated fixes for 0.15
>             ------------------------------------------------------------
>             revno: 2323.2.3.1.1.1.6
>               merge jam's integrated changes from trunk
>         ------------------------------------------------------------
>         revno: 2323.2.3.1.3
>           (mbp) more integrated 0.15 fixes
>             ------------------------------------------------------------
>             revno: 2323.2.3.1.1.1.12
>               These changes still intended for 0.15 branch
>             ------------------------------------------------------------
>             revno: 2164.2.10
>               merge bzr.dev
>             ------------------------------------------------------------
>             revno: 2164.2.20
>               merge bzr.dev
>             ------------------------------------------------------------
>             revno: 2164.2.27
>               Merge bzr.dev
>     ...
>
>
> And it seems that the merge of 0.15rc2 reverts the change to the bzr
> version string.
>
I had a couple of WTF moments when I was testing as well.
It certainly could be made clearer as to why a revision is relevant to
the file in question.

> Anyway, this still seems "correct" to me. What would have helped is if
> "bzr log --verbose bzr" would have showed the deltas for each revision.
> So that I could have seen which merged revision actually modified 'bzr'.
> As is, I had to manually do "bzr status -r before:X..X" until I found
> one that claimed a change.
>
Sounds familiar.  I even wrote a script that just took X.

> But that can wait for 0.17 :)
>
We could mark the revision which contains a content change as opposed
to just the ancestry.


Cheers,
Kent.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGLUSogoxTFTi1P8QRApfKAJwJoybhbh9nk4xlmLltSTQb4GHB3wCgxB6y
rKwfMg3n3yGJ1A18BFUZmTk=
=wry0
-----END PGP SIGNATURE-----