2009/1/11 Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>:
> Simon Large <simon.tortoisesvn_at_googlemail.com> wrote:
>> What are tree stripes? I tried that option on a graph of the TSVN docs
>> and it seems to do nothing.
>
> Under normal conditions, the revision graph is a tree.
> The following two operations may fragment it into
> a forest, i.e. collection of trees:
>
> * filtering. Ex.: open the filter dialog and say "branches"
> in the lower edit box. Make sure the check box below
> is not checked. Now, most tags should have lost their
> connection to the main tree. Specifying a suitable
> revision range will yield a similar effect.
>
> * splitting the tree
>
> Since I use the splitting feature for long but "slender"
> histories, I had difficulties to visually group the nodes
> into trees: only following the ancestry would reveal
> whether neighboring nodes belong to the same tree.
> Even the double spacing between trees is not enough.
>
> This is where "tree stripes" (I'm definitely open to
> better wording here) kick in: If the graph consists of
> more than one tree, the background color will be
> slightly modified in an alternating pattern. Just enough
> to create a contrast at the tree boundary.
>
> It is an option for two reasons:
>
> * people may want a "pure white" background
> * while I certainly want to activate the feature with
> the second operation, I may not want it after
> filtering.
>
>> I can't see what "shift trees to top of window" does. On the TSVN docs
>> graph nothing changes.
>
> Again, this applies to the multiple trees case only.
>
> Although the UI option suggests otherwise, the
> "natural" node order places revision 1 into the
> left top corner. Consequently, if you show the HEAD
> an the top, all trees will still start at the same
> *bottom* coordinate. "shift trees to top" prevents
> that.
>
> Things become even more interesting with "non-grouped"
> or "revision-order-true" graphs: Even after filtering
> or splitting, the nodes retain their vertical position.
> "shift trees to top" eliminates that "cohesion".
> However, the gaps within a tree will not be removed,
> even if they could.
>
>> What does 'check working copy for modifications' do? I have a modified
>> file withing TSVN docs, but nothing changes on the graph when I select
>> that button.
>
> This will work for working copy paths only.
>
> It should (at least after F5) give a red extra node.
> That node will appear above HEAD if your working
> is recent enough. Otherwise, it will branch from
> the BASE revision, if a newer node is shown as well.
Ah, it does work. I forgot the F5. How about adding an automatic WC
crawl when that option is switched on?
>> When I split a sub-tree the base of the split sub-tree overlaps the
>> next child node (subtree-overlap.png)
>
> I noticed that as well for certain combinations of
> options. I will look into this one.
>
> BTW, I can see that "tree stripes" is active in that
> picture: noticed that yellowish-blueish background?
If I crouch down on the floor and look up at the screen I can just
about see a difference in the backgrounds on my LCD monitor ;-)
Seriously, that is a very low contrast.
Also, where are those colours derived from? Vision impaired users need
to be able to set the colours, either through display properties for
standard Windows dialogs, or through the TSVN properties.
>> The base of a branch and the following revision are touching which
>> makes it impossible to determine which rev the [-] popup button will
>> act on (collapse-which.png)
>
> That is indeed a problem. My solution so far is
> the the glyphs have asymmetric borders: the light
> side points to the node they belong to (does
> not apply to the right side of the node). In your
> example, they belong to r13316 and you will
> collapse the older tree.
Can you add a joining line between the branch base and the next
revision so that the boxes are not touching?
> Also, the glyphs are shown for the node that
> you were over or closed to when they appeared.
> In other words: enter the node and move to
> the glyph area and they will behave just as
> expected.
Yes, I did notice that too.
>> When I select a vanilla revision (white rect) the colour does not
>> change to indicate that it is selected.
>
> Oops.
>
>> When I select a revision and change the view (grouping, split, show
>> all revs, etc), the view reverts to the top left corner. It would be
>> good to keep the selected item within view.
>
> Maybe, I can fix that.
>
>> When I collapse a following tree the box maybe positioned right at the
>> top of the graph, so [+] button is mostly off the graph
>> (collapse-top.png - the [+] is at top centre)
>
> That one is related to the overlap issue.
Maybe just leave a little free space at the top of the graph?
>> Is it possible to have a tooltip with those popup buttons? Maybe I
>> just need to get used to them. Or maybe there should be a 'legend' box
>> which can be shown in the bottom right corner.
>
> I will give the tooltips a try. They could also
> say things like "hide revision 13309 and older".
That would be good :-)
> In yours and Stefan's screenshots, I noticed that
> the toolbar is missing the last two icons. Would
> it be possible to make them a few pixels wider?
Doh! Never noticed that. The tooltip would have helped me too.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
Received on 2009-01-12 01:32:53 CET