[RFC] Change to use 'merge_sort' for per-file-log

[Robert Collins]

On Mon, 2008-09-22 at 10:08 -0500, John Arbash Meinel wrote:

> Now, I have a plugin that does what you are saying:
> lp:~jameinel/+junk/bzr-file-log. Doing "bzr file-log foo" will only show
> A and C.
> 
> bzr 1.7 will show A, C, E, F
> bzr 1.8 (if this change is merged) will show A, C, E.

It would be a little easier to say if the graph you used to demo was
flattened in merge-sort layout, but I think showing ACE is sensible
because:
A, C must be show (they are the per-file changes).
E merged C (travelling from depth 1 to depth 0). I think this is
interesting because of either of a couple of definitions.
 - 'foo is different against the lha (usually the vertically aligned   
   predecessor in logs output)
 - E is a merge towards the mainline and the change propogates there

We could use:
 - 'foo' is different against any ancestor
but I don't think this is good as *every merge* will show up propogating
the change.

Now, we treat the LHA a little special for revision numbering, and I
think it still makes sense here, because on *my* branch, I have a
relative mainline, so I'll see merges of 'trunk' as merges into my
branch, and thus get useful results. I think this is more useful than
not showing 'E' because merges to mainline tend to group work and thats
useful to show at once.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080925/cf67a51a/attachment.pgp