Making revision graphs easier to read
Glenn
graphs are relatively new and users must have been struggling without
them for a long time, from my point of view they are and always
have been part of TortoiseSVN. As such they are very helpful and
could use a few tweaks to make them even more helpful.
1. The manual needs _pictures_ of each of the types of revision
graph nodes. Verbal descriptions are ok but a picture is worth...
2. It seems that there are various combinations of icons and node
shapes. The pictures in the icons don't seem to be mentioned at
all in the documentation. For example, one of these
icons shows a pencil. What does
it indicate? Searching for "pencil" in the manual brings no hits.
Again, showing all the combinations of shapes & icons
or two separate sections: one
showing shapes with descriptions, and another showing icons with
descriptions might do the job. The "Icon Overlays" dictionary in the
documentation is a good example of this kind of thing.
3. Furthermore each node has a color. What do the colors mean?
Ok, while researching something else I just stumbled on the answer
in the Settings -> Color screen. I suggest the documentation for
this screen have two subsections titled, "Status and Action Colors"
and "Revision Graph Node Colors." That way searching for "Revision
Graph" will bring up this section (currently the only reference to
"revision graph" is in the screenshot which is, of-course, not
searchable. I also suggest adding a sentence to the "Revision
Graph Nodes" section that says you can look up and control the
colors for different types of nodes using the Settings -> Colors
screen.
4. Maybe some text could be added to the box that appears when you
roll the mouse over each revision graph node. It could
say something like Tip Node, added/deleted/renamed node, initial branch node, etc.
5. When you use the right-drag "move versioned files here" command
the resulting file has a revision graph that shows a branch node.
This is not consistent with the description of this command in the "Commit the parent folder" caution box in the "Moving files and folders".
It says, "moves are done as delete followed by add." Given that the
branch node appears there must be a _copy_ involved? Is the display
of the destination node in the revision graph correct to label it as
a branch? I guess svn makes no distinction between copying and
branching so this is ok although I wonder why the "move versioned files
here" command doesn't use the underlying svn move command instead of
the copy followed by add which it seems to use.
I hope you find these comments helpful. I used ClearCase for many years
with code with lots of branches and merges. I relied heavily on their
revision graphs so I guess I have high standards. I really like TortoiseSVN and hope my contributions can help make it really solid.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-un...@tortoisesvn.tigris.org
For additional commands, e-mail: users...@tortoisesvn.tigris.org
Simon Large
> I've just started to use TortoiseSVN so even though the revision
> graphs are relatively new and users must have been struggling without
> them for a long time, from my point of view they are and always
> have been part of TortoiseSVN. As such they are very helpful and
> could use a few tweaks to make them even more helpful.
>
> 1. The manual needs _pictures_ of each of the types of revision
> graph nodes. Verbal descriptions are ok but a picture is worth...
OK, I'll see what I can do.
> 2. It seems that there are various combinations of icons and node
> shapes. The pictures in the icons don't seem to be mentioned at
> all in the documentation. For example, one of these
> icons shows a pencil. What does
> it indicate? Searching for "pencil" in the manual brings no hits.
> Again, showing all the combinations of shapes & icons
> or two separate sections: one
> showing shapes with descriptions, and another showing icons with
> descriptions might do the job. The "Icon Overlays" dictionary in the
> documentation is a good example of this kind of thing.
I may need some help with the descriptions on this one. Stefan^2?
> 3. Furthermore each node has a color. What do the colors mean?
> Ok, while researching something else I just stumbled on the answer
> in the Settings -> Color screen. I suggest the documentation for
> this screen have two subsections titled, "Status and Action Colors"
> and "Revision Graph Node Colors." That way searching for "Revision
> Graph" will bring up this section (currently the only reference to
> "revision graph" is in the screenshot which is, of-course, not
> searchable. I also suggest adding a sentence to the "Revision
> Graph Nodes" section that says you can look up and control the
> colors for different types of nodes using the Settings -> Colors
> screen.
Good point.
> 4. Maybe some text could be added to the box that appears when you
> roll the mouse over each revision graph node. It could
> say something like Tip Node, added/deleted/renamed node, initial branch node, etc.
One for Stefan/Stefan^2
> 5. When you use the right-drag "move versioned files here" command
> the resulting file has a revision graph that shows a branch node.
> This is not consistent with the description of this command in the "Commit the parent folder" caution box in the "Moving files and folders".
> It says, "moves are done as delete followed by add." Given that the
> branch node appears there must be a _copy_ involved? Is the display
> of the destination node in the revision graph correct to label it as
> a branch? I guess svn makes no distinction between copying and
> branching so this is ok although I wonder why the "move versioned files
> here" command doesn't use the underlying svn move command instead of
> the copy followed by add which it seems to use.
SVN does not support true renames, and the svn command line client
also does a copy and delete. You are correct that the 'delete followed
by add' description is misleading. It should be 'svn copy followed by
delete'.
> I hope you find these comments helpful. I used ClearCase for many years
> with code with lots of branches and merges. I relied heavily on their
> revision graphs so I guess I have high standards. I really like TortoiseSVN and hope my contributions can help make it really solid.
Thanks for your input. Comments and suggestions are always welcome :-)
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
Stefan Küng
> 2008/9/2 Glenn <ozn...@yahoo.com>:
>> I've just started to use TortoiseSVN so even though the revision
>> graphs are relatively new and users must have been struggling without
>> them for a long time, from my point of view they are and always
>> have been part of TortoiseSVN. As such they are very helpful and
>> could use a few tweaks to make them even more helpful.
>>
>> 1. The manual needs _pictures_ of each of the types of revision
>> graph nodes. Verbal descriptions are ok but a picture is worth...
>
> OK, I'll see what I can do.
>
>> 2. It seems that there are various combinations of icons and node
>> shapes. The pictures in the icons don't seem to be mentioned at
>> all in the documentation. For example, one of these
>> icons shows a pencil. What does
>> it indicate? Searching for "pencil" in the manual brings no hits.
>> Again, showing all the combinations of shapes & icons
>> or two separate sections: one
>> showing shapes with descriptions, and another showing icons with
>> descriptions might do the job. The "Icon Overlays" dictionary in the
>> documentation is a good example of this kind of thing.
>
> I may need some help with the descriptions on this one. Stefan^2?
The pencil icon means the node was renamed.
green arrow : last commit
pencil : renamed
two papers connected with a green arrow : replaced and also "tag" (I
guess we have to get someone to draw better icons :)
the other icons should be obvious.
the shapes are as follows:
octangle: deleted, replaced, renamed
rounded rect: added, added with history (i.e., a copy)
ellipse : last commit on that branch/tag/trunk
rectangle : all other (normal) nodes
>> 3. Furthermore each node has a color. What do the colors mean?
>> Ok, while researching something else I just stumbled on the answer
>> in the Settings -> Color screen. I suggest the documentation for
>> this screen have two subsections titled, "Status and Action Colors"
>> and "Revision Graph Node Colors." That way searching for "Revision
>> Graph" will bring up this section (currently the only reference to
>> "revision graph" is in the screenshot which is, of-course, not
>> searchable. I also suggest adding a sentence to the "Revision
>> Graph Nodes" section that says you can look up and control the
>> colors for different types of nodes using the Settings -> Colors
>> screen.
>
> Good point.
>
>> 4. Maybe some text could be added to the box that appears when you
>> roll the mouse over each revision graph node. It could
>> say something like Tip Node, added/deleted/renamed node, initial branch node, etc.
>
> One for Stefan/Stefan^2
Is that really necessary? The action/operation is shown in the urls (and
the copyfrom url).
Stefan
nmgeek
I think adding text to identify the node type would really help people
learn
the symbology in the revision graph. Also, I don't see a copyfrom url
in the
roll-over popup.
Here are a couple other comments after another day of using the
revision
graph:
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.
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.
7. Are there supposed to be merge lines? I can see the branch lines
but
no merge lines.
8. It would be really helpful to show an additional node above the
head
node when the file is modified in the working copy.
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.
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.
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.
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.
Thanks,
Glenn
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
> signature.asc
> < 1KViewDownload
Stefan Küng
> I think adding text to identify the node type would really help people
> learn
> the symbology in the revision graph. Also, I don't see a copyfrom url
> in the
> roll-over popup.
>
> Here are a couple other comments after another day of using the
> revision
> graph:
>
> 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.
But some people don't like that node.
> 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.
Stefan^2 already made some changes there on his revision graph branch.
> 7. Are there supposed to be merge lines? I can see the branch lines
> but
> no merge lines.
No, merge lines are not implemented. Because Subversion doesn't provide
the APIs we would need for it. We could work around that and ask the
repo for the required info ourselves, but it would take a few seconds
for *each* revision - imagine the TSVN repo with > 10000 revisions: it
would take ages to get the graph.
> 8. It would be really helpful to show an additional node above the
> head
> node when the file is modified in the working copy.
Above the head? Your working copy can't be above the HEAD.
> 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.
good idea.
> 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.
>
> 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.
Yes. That means that we think it's a good idea and will
implement/improve/... that feature. It does not mean that we file an
issue for it though.
Speaking for myself: I usually move such mails to a special folder in my
mail client. Whenever I have time I go through that folder and pick some
task to do. Sometimes however if I start working on a task and then
realize that either the feature is not good or that it's not possible to
implement it (e.g., some API doesn't return the required info), then I
just drop it - but that doesn't happen often.
> 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.
Don't worry, you're doing it right :)
The reason I don't really like the issue tracker is that it's more work
than necessary. Keeping the corresponding mails in a separate folder is
much easier.
Simon Large
> nmgeek wrote:
>> 8. It would be really helpful to show an additional node above the
>> head
>> node when the file is modified in the working copy.
>
> Above the head? Your working copy can't be above the HEAD.
I think he means local modifications in the working copy. However I
don't think that is a good idea for a couple of reasons:
1. It only works when invoked for a working copy, otherwise the rev
graph won't know where to look for changes. That might cause the
unwary to believe that there are no changes, when in fact they have
called the rev graph from the repo browser, or from another branch.
2. It means a WC crawl which could take a long time for a large WC.
3. Your local changes may not be against HEAD anyway. Others may have
committed changes since you last updated.
>> 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.
>
> Yes. That means that we think it's a good idea and will
> implement/improve/... that feature. It does not mean that we file an
> issue for it though.
>
> Speaking for myself: I usually move such mails to a special folder in my
> mail client. Whenever I have time I go through that folder and pick some
> task to do. Sometimes however if I start working on a task and then
> realize that either the feature is not good or that it's not possible to
> implement it (e.g., some API doesn't return the required info), then I
> just drop it - but that doesn't happen often.
In gmail I star any emails that indicate changes I need to make to the
docs. I did have an open documentation issue for 1.5, but starring the
emails is easier. If someone else wants to contribute I can go back to
using the issue tracker to make it easier to share.
Thanks for your comments Glenn, well thought through feedback is
always appreciated.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
nmgeek
It took me a while to get back to this discussion: I was training an
office of IT folks
how to use TortoiseSVN.
I'm interested in persuing the creation of a merge API in subversion
which
would support implementation of merge arrows in the revision graph
view. What are you looking for here? Is there anyone you would
recommend
collaborating with on the Subversion project?
One nit from the training: After you do an TSVN->add the "+" icon
overlay typically
appears over the .svn folder (first folder in the list) until you
refresh the screen
to fix it.
I have more to add to this discussion but right now I want to get on
the Subversion
merge arrow API thing while I have some time available to work on it.
Thanks!
Stefan Küng
> One nit from the training: After you do an TSVN->add the "+" icon
> overlay typically
> appears over the .svn folder (first folder in the list) until you
> refresh the screen
> to fix it.
Please read my explanation here:
http://groups.google.com/group/tortoisesvn/msg/138edbe08f5353c7
Simon Large
This conversation came up about 4 months ago and seemed like a good
idea, but I don't think it has made it in yet. Worth doing?
2008/9/3 nmgeek <glenn.to...@gmail.com>:
> 8. It would be really helpful to show an additional node above the
> head node when the file is modified in the working copy.
Already done :-)
> 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.
Seems like a useful plan. What do you think?
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1056379
To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
Stefan Fuhrmann
> This conversation came up about 4 months ago and seemed like a good
> idea, but I don't think it has made it in yet. Worth doing?
>
> 2008/9/3 nmgeek <glenn.tortoisesvn_at_gmail.com>:
> > 8. It would be really helpful to show an additional node above the
> > head node when the file is modified in the working copy.
>
> Already done :-)
>
> > 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.
>
> Seems like a useful plan. What do you think?
Implemented in a series of patches that handle
diffs on and against the 'modified WC' node.
Latest revision: r15531.
-- Stefan^2.