Simon Large <simon.tortoisesvn_at_googlemail.com> wrote:
> >> 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?
Actually, it should. I tried it with /trunk and it
automatically crawled the WC the *first* time,
one of the two options is activated. Changes
after that won't discovered until F5 forces an
update.
Do you have a reproduction recipe?
r15102 disables those 2 buttons for URLs.
> >> 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.
It's bad on my notebook, too. Maybe it has
only 6 bit / color resolution. All desktop-LDCs
reproduced the colors clearly and over a wide
angle.
So far, those colors have been hard-coded.
Seems that I will need a whole new page
for revision graph colors (5+ node colors,
2 background stripes plus alpha channel).
That won't happen before the weekend.
Until then, r15203 has 50% more contrast.
> >> 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?
That's my fallback idea. But I hope I can
find the reason for those "asymmetric" shifts.
> > 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.
I tried something in r15101. Is that something
we could improve on? Any comments?
> >> When I select a vanilla revision (white rect) the colour does not
> >>
> >> change to indicate that it is selected.
> >
> > Oops.
Fixed in r15099.
> >
> >> 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?
That too, would be plan B.
> >> 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 :-)
But not today ;)
-- Stefan^2
Received on 2009-01-13 23:08:19 CET