On Fri, Aug 14, 2009 at 12:38 AM, Peer Sommerlund<peer.sommerl...@gmail.com> wrote: > > 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.
You're right. I think the row coloring confused me somehow. >> 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. Beware that on the tip of the default branch the filter dialog may soon be gone. -- Steve Borho ------------------------------------------------------------------------------ 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
