"Hans-Emil Skogh" <Hans-Emil.Skogh@tritech.se> wrote:
> It is all about how to allocate the boxes in the graph in different
> columns a bit more intelligently. The goal is to get something akin to
> putting all tags in one single column and all branches/renames in
> separate columns.
This is certainly something we want to implement. Currently,
I focus on improving NSR, i.e. intelligent ways to remove / hide
"unimportant" nodes.
For now, at least I am still learning what information I might
get from the revgraph (in addition to just being nice, colorful
and sometimes impressive) and what options are helpful to find it.
> I would go as far as to suggest that there are two different cases that
> have to be handled when laying out a revision graph.
My idea is to have a set of basic layouts (currently two) plus a
number of mostly generic tweaks that mainly act as filters.
> --- 2006-02-03 ---
> Sometimes it's
> highly practical when multiple different paths end up in the same column
> (tags for example) and otherwise one would like to keep each unique path
> in a unique column (typically with branches). Unique columns would also
> facilitate collapsing/folding.
Correct. I thought of something like placing the "main line of
development" (usually trunk) in the middle, while allowing
branches / tags to fork to *both* sides. On special layout may
put all "tags" to the left and all "branches" to the right.
We might also alternating background coloring and / or dotted
lines to visually separate those columns.
However, there is a basic problem with all those approaches:
Different projects may use different repository layouts, branch
and tag policies. Most importantly, they may also use entirely
different naming convention. Example: a company may use SVN for
document management and call their trunk "draft" and their tags
"QAx". But I am already thinking about a solution here.
An smaller issue related to this is that many projects don't tag
from the /trunk but from (stabilization / maintenance) branches.
Hence, separating them will obscure the "meaning" or "content"
of the individual tags. Once way to relax that issue would be
placing "non-tagging" branches (i.e. feature or developer branches)
to the right while all "tagging" onces are put to the left.
> Now the revgraph creates good layout (imho) for graphs showing tags, but
> less good for complicated branching or copying.
It will get *much* harder to layout when merging is shown as
well.
> --- 2006-02-07 ---
> Column assignment for an item is done in the following way:
> If a copy is made, the copy destination is checked for later
> modifications.
> - If it has modifications it will be added to a column named after the
> destination file's path and with the "tag"-state set to false. If no
> such column exists, one is created.
> - If no modifications are made it will be added to a column named after
> the source file's path, but with the "tag"-state set to true. If no such
> column exists, one is created.
The current "tag" detection works similarly but must be extended
to "fold" even more complex tag operations. See next post.
> --- 2006-02-09 ---
[snip basically same idea].
Despite of that, I think your column assignment and naming proposal
is a good one.
-- Stefan^2.
Received on Thu Jul 12 14:26:29 2007