On Mon, Mar 16, 2009 at 5:50 PM, Peer Sommerlund <[email protected]> wrote: > Hi there > Have anybody tried to design a revision graph that does not make lots of > strings when using the repeated-merge-pattern? > Take a look at THG crew revisions 1545:1728 in hgtk log to see what I mean. > Here Simon Heimberg's changes were added. > > > Would it be possible to only make a new swim-lane if a head was created at > the time of the changeset? > An algorithm like this > heads = empty > for each changeset from old to new > count number of parents to changeset that are also in heads > 0: make a new swimlane for the new head > 1: use swimlane for that head > 2: replace primary head (or leftmost head) and delete other swimlane > It would require a new changeset glyph that indicated a merge, but only had > a line to one of the parents
I think what you mainly need to do would be to list the revisions out of order. If you followed lines of development from heads through ancestors rather than walking down revision IDs, you end up with much fewer open lines of development. It's a potentially bi-directional walking algorithm, though. I'm not aware of any tools that actually use it. I think I've heard of prototypes, though. -- Steve ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
