[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SV: Revision graph rewrite

From: <Stefan.Fuhrmann_at_etas.de>
Date: 2007-07-12 14:27:02 CEST

"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

> --- 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

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.