Comment 9 for bug 321389

On Sat, Jul 11, 2009 at 6:07 PM, Maarten Bosmans<email address hidden> wrote:
> 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.

To get the real timestamp, you have to load the revision, which is
really slow. At the moment, we only load the revision when it is
displayed on screen. So I think there are 2 options:

* Use a regular expression to extract date str from the revid.
  Pro: Will be fast because it won't have to load all the revisions.
  Con: Won't work if the revid is not a bzr revid, e.g. on a bzr-svn branch.

* Load all the revisions. Because this is slow, I would say you need
to make topo sort the default, and only do this if the user
specifically asks for it.
Pro: Will work for any type of branch.
Con: Slooooow.

I don't really understand the merge_sort/topo_sort to be able to tell
you if it would make sense to do it as a part of that merge_sort code,
or if we should just do a second pass. The I think the best person to
ask about this would be John Meinel.

For qlog, we would need to do 2 passes, because we use information
gathered from the order, and the merge depth do work out what merges
what.