2009/3/17 Steve Borho <st...@borho.org>
> On Mon, Mar 16, 2009 at 5:50 PM, Peer Sommerlund
> <peer.sommerl...@gmail.com> 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.
>
I'm trying to implement it, and will send patches when it is ready.
Regards,
Peer
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Tortoisehg-develop mailing list
Tortoisehg-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
