Comment 8 for bug 321389

It wasn't easy to grok the merge_sort code, so as a first try I just reordered the result from merge_sort in a separate pass in linegraph.py. This has the disadvantage that the code isn't generic, but bzr-gtk specific.

This patch can be viewed as a proof-of-concept. It is nice to see for example how the commits on diverging branches of a large project relate in time. In general however, I think the generated tree is a bit more messy to look at, so may be this sort mode shouldn't be the default.

The two main problems with this patch are:

* The revisions aren't really sorted by date, but by revid, which happens to have the format commiter-datestr-hash, so sorting on that gives approximately the expected result, at least for my single-commiter project. As far as I can see the linegraph hasn't got enough information to extract the revision timestamp from the list of revids. So may be the code has to move even higher up, where this information is available.

* The topological order isn't preserved for commit's with incorrect timestamps. There several possible ways of fixing this, but I'll wait with that until we have decided the correct place for this code

Gary, do you still think merge_sort is the right place for this code? If so, how do you propose the revision timestamp gets exposed to this function? May be the function call should have a reference to the repository, so it can look up the timestamp, or better yet the sort function could have a comparison function to sort by after the topological sort as an argument.

The next two weeks I'm on holiday, so after that I'll work on this again. But if anybody could try to fix this in the mean time, that would be great too.