2009/8/13 Steve Borho <st...@borho.org>
> On Thu, Aug 13, 2009 at 9:49 AM, Peer
> Sommerlund<peer.sommerl...@gmail.com> wrote:
> >> 2009/8/10 Peer Sommerlund <peer.sommerl...@gmail.com>
> >>
> >>
> >> 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
> >
> > It is not yet ready for prime time, but anybody interested can test the
> code
> > at
> > http://bitbucket.org/peso/thg-branch-view/
> >
> > Note this is a patch branch repo. The code lives at branch "branch-view".
>
> That looks pretty promising. It makes a big difference on repos like
> hg-stable.
>
> Some people may be unsettled by the non-linear nature of the revision
> numbers, but I'm guessing most wouldn't notice.
The algorithm walks revision numbers sequentially from high to low, so they
have the same order as in the existing algorithm. The difference is that a
merge may show up twice, and although lines link the correct branch, they
may not link to the correct revision.
>
>
> How difficult would it be to make it toggleable?
>
My plan was to make it optional, so both kind of graph views were available.
I'm trying to come up with a more intuitive way for the filter and datamine
buttons to work.
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
