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

[Kent Gibson]

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



John Arbash Meinel wrote:
>
> Interestingly enough, because of the extra work, for a short number of
> revisions of a heavily modified file, your version is actually slower.
>
Yup, the ancestry has to be calculated for all revisions, no matter
how many are going to be displayed.  For a small number of revisions
to display the delta approach, slow as it is, will be faster than
ancestry generation over thousands of revisions.

Unfortunately I can't think of any way to simplify the ancestry
generation for a small number of recent revisions.  If you prune the
revision graph at some arbitrary point you can loose whole branches of
ancestry.

And I'd rather not have to use some heuristic to switch between the
two approaches.
Since the delta approach can miss ancestry changes, there is the
potential of different output depending on which algorithm is used.
> At least for me:
>
> bzr log --short -r-10..-1 NEWS
>
> takes 5.6s with bzr.dev and 14.8s for your version.
>
For me it is 1.32 for bzr.dev and 2.66 with my patch.
On my machine the cross-over point seems to be about -r-30..-1
> Now, it is modified by almost every version in the mainline, so it is
> sort of an extreme case.
>
> bzr log --short -r-10..-1 INSTALL
>
> Is 2.875s versus 6.143s for bzr.dev.
My patch is faster for this case on my machine as well - 0.76sec
versus 1.2 for bzr.dev.
So it should be good for files/projects with a small number of
revisions - bzr.dev NEWS being a prime example of the other end of the
spectrum.

>
> I'll see what we can do to make correctness not cost so much. (And get
> everything well tested).
>
Any luck with that?

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

iD8DBQFGLICvgoxTFTi1P8QRApc/AKChpWVEdBwCN0zhiW0leIxB1YVm0wCfWDsG
ip9H0UUjN7cqcFFukUUUKGY=
=4TLd
-----END PGP SIGNATURE-----