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

[John Arbash Meinel]

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

Robert Collins wrote:
> 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

I agree with all of these points. I also think people have a better intuitive
feel for when we log it in this fashion. Going by a strict "bzr log -v"
usually ends up with people wondering why that node was included (not intuitive).

My only concern was that:

bzr log --show-ids brancha/file | grep 'revision-id' | sort

will give a different output than

bzr log --show-ids branchb/file | grep 'revision-id' | sort

So if I had my choice, I would probably explicitly flag the revisions that are
only there because they merged the change closer to the branch mainline.


I will note when talking with Guilhem (Guilheim?) about MySQL, that he is
concerned they have too many intermediate branches, and that the merge nodes
will become too noisy. (5.0-xxx => 5.0 => 5.1-int => 5.1 => 6.0, etc)
So I would consider having a flag for it. But we can cross that when people
decide it is important.

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

iD8DBQFI2t7/JdeBCYSNAAMRAmncAJ9k7Qfa4A0ij6/4Z0OVYtYm8BWVVQCfW49F
22ca58XB2MB6dDN6WpU0oZQ=
=PfJt
-----END PGP SIGNATURE-----