> the revision graph as implemented on /trunk has a few
> issues with mid- and large-sized repositories.
...
> Since I hear quite a few similar complaints from my
> colleagues, I wondered if I could do better ;) This is
> what I did on /branches/RevisionGraphRewrite:
Ah! Nice that someone found the time to do some serious work on the
revgraph. I'll now take the chance to bring up an idea that I pitched on
the list in the beginning of 2006.
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.
I'll copy the text from some of the mails below. Watch out for a long
mail... (Basically three mails trying to describe more or less the same
thing in different ways.)
--- 2006-02-03 ---
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. 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.
Now the revgraph creates good layout (imho) for graphs showing tags, but
less good for complicated branching or copying. The graph generated by
the revgraph is hard to read and not very suitable for the information
being presented. The suggested one contains exactly the same
information, but with each unique path in a separate column. (Columns
being generated left to right where columns are ordered in order of
creation.)
--- 2006-02-07 ---
To implement my suggestion, the only thing that would have to be
modified is the columns of the graph and when to create them. The
modification would be done in the following way:
Firstly each column must be able to have a string path and a boolean
"tag"-state associated with it.
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.
--- 2006-02-09 ---
Each column must be able to have a string path and a Boolean "tag"-state
associated with it.
If the item is a "tag", it should end up in a column dedicated for tags
that originate from the same source path as the item.
//// Confusing example start ////
I'll try to explain with a short use-case with a regular repository
layout:
Rev 1: Repository layout created
....some work is being done in trunk
Rev 35: /trunk is copied to /tags/0.1
....more work in trunk
Rev 43: /trunk is copied to /branches/featurex ....work is being done in
trunk and featurex Rev 58: /trunk is copied to /tags/0.2
When the graph is being laid out (on trunk), the following should
happen:
Rev 1: /trunk has modifications later on and no suitable column is
found, therefore a new column is created named "/trunk NOTAGS" and the
item is placed there.
Rev 34: /trunk has modifications later on and a suitable column is
found, the item is placed in "/trunk NOTAGS".
Rev 35: /tags/0.1 has NO modifications later on and no suitable column
is found, column "/trunk TAGS" is created and item placed there.
Rev 42: (Identical to rev 34.)
Rev 43: /branches/featurex has modifications later on and no suitable
column is found, column "/branches/featurex NOTAGS" is created and item
placed there.
Rev 57: (Identical to rev 34.)
Rev 58: /tags/0.2 has NO modifications later on and gets placed in
column "/trunk TAGS".
//// Confusing example end ////
The point being:
"Tags" should be placed in a column named after the source path (of the
copy operation) and with a "tags"-flag set. (In the confusing example
illustrated appended to the column name.) Non-"tags" should be placed in
a column named after the item's own path with the "tags"-flag unset.
--- Today ---
There has been some work on organization of the graph since I wrote the
suggestions above, but I think that there's still work left to do.
Any thoughts?
Hans-Emil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Jul 10 10:34:18 2007