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

Re: Making revision graphs easier to read

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Sat, 13 Sep 2008 16:09:08 +0200

nmgeek <glenn.tortoisesvn_at_gmail.com> wrote on 3 Sep 2008 14:33:58

> 5. I don't see any reason to have the button that turns on/of "Show
> HEAD revision nodes". Just show them all the time ... it would be one
> less button in the GUI to get confused about.

Hm. With 1.5.x, I was happy about every option that saved
me a few nodes here and there. Maybe, we can drop it in
1.6 but I'm slightly biased against it. A better way to handle
the usability issue would be re-arranging the buttons and
enabling the "Show HEAD" per default.

Anyway, TSVN should remember your current option setting,
so enable and forget it ;)

> 6. Also, whereas the highlight outline graphic which shows
> the current version in the working copy is _black_ for square nodes
> it is _grey_ for HEAD/eliptical nodes. The grey is hard to see ...
> it's hard to
> see it's there at all. It makes more sense to show it in black like
> with
> the other nodes.

Fair point. I will change that.

> 7. Are there supposed to be merge lines? I can see the branch lines
> but
> no merge lines.

The short answer is: "No". Details are less simple. My goal
is to show merge information and finally offer a graphical
merge based on that information.

However, there are at least two issues that need to be solved.
First, there is no SVN API that gives us the necessary information
within reasonable time. The other problem is that merge lines
are not at all sufficient to visualize the change flow. Some of
edge-cases are listed here:

http://svn.haxx.se/subdev/archive-2008-08/0052.shtml

> 8. It would be really helpful to show an additional node above the
> head
> node when the file is modified in the working copy.

Good idea. Actually, it should have the working copy
revision node as a parent making it look like a branch
in many cases. That would be strictly correct.

Of course, it would be opt-in and may take a while
to get the required information. But with "WC rev"
already shown and a decent amount of RAM installed,
the overhead should be a second or so for larger
but not huge working copies.

> 9. If you have the modified node displayed then you can add right-
> click
> menu command for "diff with HEAD" (for the modified node),
> "diff with previous version" for committed nodes, and a general "diff
> with selected node" which would really, really help you see what you
> are about to get into with an upcoming merge.

Diff between arbitrary nodes is already possible. However,
"diff to previous / next *shown* revision" would be a good
extension.

> Maybe from these suggested enhancements you can see how the revision
> graph can be the _primary_ screen for exploring branched version
> history and
> understanding and executing merges.

My idea is to make it the "power user tool" even if that
may take years to complete.

From today's perspective, however, it cannot be the
"central tool" for all users. Part of TSVN's, and therefore
SVN's, success is its incredible usability: "click-click
and be done". So, most interactions will rather get a
simpler UI than a more convoluted one.

> I have a process question: When you or Simon answer with
> something like "good point" should I interpret that as, "yeah
> I'll improve the documentation so this is addressed" or is it
> up to me to file an issue against the documentation to help insure
> its addressed in the documentation.

In addition to what already has been said: I, personally,
treat such valuable input as, well, "input". Its going to be
processed, i.e. it may sit for some time while other ideas
get implemented. After some time, I get back to the "ideas"
stack. And, if it still fits the general design ideas, it will
materialize one day.

My experience is that over time, some proposals become
obsolete because a much better, more general approach
has been realized. Others may turn out not to achieve
their goals and finally get removed from the code. That's
normal SW development business.

The most important message I can send here is "yes,
I'm / we are working into the same direction as you would
want me / us to".

> I understand everyone is volunteering their time (even me
> in this case). I also understand that even volunteers
> like to follow a well defined process. So I'm (hopefully
> respectfuly) just checking in on the process.
>
> I appreciate this wonderful tool you have put together and look
> forward
> to it getting better and better.

Once the initial phase of the revision graph rework
is done, probably in October, I will merge it for 1.6
and notify the dev@ list (I'm not subscribed to the
users@ list).

It would be great if you could then give some feedback
on it.

-- Stefan^2.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-09-13 16:08:39 CEST

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

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