Re: Changing topo sort behaviour

Greg Ward wrote:
> On Thu, Aug 6, 2009 at 1:08 PM, Michael Haggerty<[email protected]> wrote:
>>  You will note that there are several topological
>> sorts; the first involves only RevisionChangesets, then only
>> SymbolChangesets, then all Changesets.
> [...]
>> The question is, how to change this?  I don't think you want to skip the
>> chronological ordering altogether, because it helps the heuristic that
>> decides which SymbolChangesets to break up to break cycles in the
>> dependency graph.
> 
> ...ahhh, so that means I should ignore RevisionTopologicalSortPass and
> focus on TopologicalSortPass.  Thanks; I probably would have figured
> that out eventually, but I'm sure you've just saved me many hours of b
> banging my head on the wrong sort.

Yes, but...

OrderedChangesets' dependencies (which are specified by their
create_graph_node() method) are already edited to treat their immediate
predecessor and successor OrderedChangesets as direct dependencies, and
to ignore all other OrderedChangesets which (in their previous
incarnations as RevisionChangesets) used to be dependencies.
(OrderedChangesets can of course also have dependency relationships with
SymbolChangesets).  Thus the transformation of RevisionChangesets into
OrderedChangesets has changed the topology of the dependency graph in a
way that is consistent with the original graph but much more
restrictive.  Thus your later toposorts will have much less freedom to
rearrange the changesets according to Mercurial's performance-dictated
preferences.

You might consider transforming the OrderedChangesets back into
RevisionChangesets before the final toposort.  I'm not certain that it
will work, but it's at least an idea in the right direction :-)

> Oh, a related question: is there a straightforward way to figure out
> the head of a branch?  It would be nice if
> HgOutputOption.process_branch_commit() knew that it was processing the
> last revision on the current branch.  I think I could cobble something
> together in the hg-specific topo sort, but if that information is
> already available elsewhere, there's no point in duplicating it.

I can't think of an O(1) way of determining the head of a branch.  Of
course one could iterate through the toposorted changesets and simply
keep track of the last Changeset that touches a particular branch.

By the way, the branch head is only strictly defined once the final
toposort is done, because there might be ordering ambiguities that allow
two Changesets on the same branch to be committed in arbitrary order.

Michael

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2381013

To unsubscribe from this discussion, e-mail: [[email protected]].