[PATCH 0 of 3] Alternative graph web interface to better handle named branches

Degrassi Francesco francesco.degrassi at emaze.net
Tue Aug 17 14:01:01 CDT 2010


Hi Matt,​

Il 17 agosto 2010 alle 19.24 Matt Mackall <mpm at selenic.com> ha scritto:
> > The main features are:
> >  * each named branch is assigned a separate plot column and color
>
> We have some crazy people with dozens of named branches, so the column
> thing might get problematic. But they'll probably have issues with the
> current graph anyway. Also restricting activity on a named branch to a
> narrow column might also be an issue - even on the hg repo, we can get
> several columns wide on the default branch.

Where i work we use a named-branch-by-feature policy, so some of our most active
projects have dozens and dozens of those :-) and the current graph does not help
enough for our case.

The column width can be adjusted by the interface itself, I added a "narrower"
and "wider" links on the graph page for this specific case; it handles correctly
the netbeans repo, which can get more than 30 anon branches open at the same
time.

Currently the distance between anonymous branches is fixed, but that could be
made adjustable as well, maybe with some "smart", adaptive default.

> >  * anonymous branches are plotted as part of the relative named branch
>
> Perhaps we could have shades of the named branch colors to indicate
> anonymous branches?

I thought about this, but am not sure if that would be enough; I could try
experimenting with it a little bit.

> >  * named branches are plotted to the right of their parent branch
> >  * a set of "pivot" named branches can be configured, these will always be
> >plotted and other branches will be positioned relative to these; this is
> >useful for branches like "stable", "release", etc
>
> Can you tell us more about this?

Out of the box, the "default" branch is the only pivot branch, but this can be
configured.

Pivot branches are always drawn in the output, even if no changesets on that
branch are included in the dag.
Pivot branches are also used to decide which column gets assigned to each named
branch; for each named branch, the algorithm navigates its ancestors and stops
when it finds a pivot branch.

The algorithm then orders the named branches in the following order:
  PIVOT#1
  <all named branches that originate from PIVOT#1>
  PIVOT#2
  <all named branches that originate from PIVOT#2>
  PIVOT#3
  ...

For example, in our projects, we set "release" and "default" as pivot branches;
this results in the release branch always being drawn in the first column,
"bugfix" branches (which originate from "release") are then drawn, then
"default" (on which the main development takes place) and on the right all the
"new feature" branches (which originate from default). This reduces crossovers
to a minimum and allows adapting the output to each project's workflow/paradigm.

This is very difficult to explain with words, but far simpler to grasp testing
the patch.

> >  * named branches are labeled on the plot
> Not sure about this piece.

We found it easier to follow complex merges this way, without constantly looking
at the right side of the screen and "rotating" our view 90 degrees each time :-)

Thanks for your feedback. Regards.

Francesco


More information about the Mercurial-devel mailing list