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

John Arbash Meinel john at arbash-meinel.com
Wed Apr 18 22:27:24 BST 2007


Kent Gibson wrote:
> 

...


> I'm despairing of any solution that requires delta generation since
> that is so damn slow.
> So I've been wondering if we can compare ancestry instead of full deltas.
> 
> Given that my initial patch provides the list of revisions with
> substantive changes to a given file (I'll call this set Rc), what we
> are trying to add are the revisions where these changes are merged
> (I'll call that set Rm).
> In the example above, at D we compare the ancestry of it's parents -
> the left (B) and right (C).
> If C's ancestry contains a revision from Rc that is not in B's
> ancestry then we should add D to Rm.  Repeat that for all merge
> revisions in the graph to determine the full set Rm.

...

> Cheers,
> Kent.

Interestingly enough, because of the extra work, for a short number of
revisions of a heavily modified file, your version is actually slower.

At least for me:

bzr log --short -r-10..-1 NEWS

takes 5.6s with bzr.dev and 14.8s for your version.

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.

I'll see what we can do to make correctness not cost so much. (And get
everything well tested).

John
=:->




More information about the bazaar mailing list