2009/8/15 Steve Borho <st...@borho.org>
> On Fri, Aug 14, 2009 at 9:33 PM, TK Soh<teekay...@gmail.com> wrote:
> > On Thu, Aug 13, 2009 at 2:49 PM, 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".
> >
> > Sorry I am not familiar with patch branch. What do I do to just pull
> > the plain changes and try them out?
> >
>
> hg clone http://bitbucket.org/peso/thg-branch-view/
You can find the documentation if you google for "patch branches" ->
http://arrenbrecht.ch/mercurial/pbranch/
The patch branch extension is similar to MQ in that it stores patches. The
differences is that where MQ stores patches as (versioned) patch files,
pbranch will store patches as named branches.
hg branches
gives you a list over patches (and other branches). You will see one new
active branch named "branch-view" which is the combination of all patches
hg up -C branch-view
brings the current version to the working directory. (corresponds to hg
qpush --all)
When the code is ready for pushing upstream, you get the patches by diffing
branch heads. The pbranch repo is then discarded. It is not intended to be
included in the upstream repo.
pbranch is much better than MQ if you have parallel development of the
patches. Merging patch repositories will make sense with pbranch, where MQ
will force you to work with second order patches.
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
