Improvements to the Annotate view
Taking some ideas from TortoiseBlame:
When right-clicking a changeset/line, add a choice "Annotate previous changeset" (this is so you can trace the earlier history of the line you're interested in).
When right-clicking a line and choosing "Diff contents of branch/changeset ...", the file that you are currently annotating should be pre-selected in the Comparison window that appears.
Use a tooltip box to display log message (and branch, date etc) when hovering the mouse pointer over a changeset/line.
Remove the horizontal color gradient. While a nice effect, it distracts from the per-date/author color gradient.
Add automatic coloring of changeset text to make sure it's visible against the per-date/author background color.
Göran Wallgren
shared this idea
-
Göran Wallgren
commented
The use-case is that you need to trace a certain block of code back in time (from the current changeset, let's say 32000) to see why and how it was changed. This must be done on a per-line basis, so the previous changeset (let's say 31000) of the whole file is pretty useless. In Annotate you can view a line/block and see at what changeset (let's say 30000) it was changed to the current reading. Then you very often want to know how that line/block read just before that latest change. That's why we need to be able to annotate the previous changeset for a specific line (let's say 29000). Your new feature takes us from cs:32000 to 31000, but we really need a way to go from cs:32000 to 29000 (line-specific)...
-
Göran Wallgren
commented
The majority of suggestions here were addressed in 6.0.16.1471, thanks! However, the most important missing feature, "annotate previous changeset", was _not_ implemented the way it's suggested here and the way it works in TortoiseBlame!
The implemented feature simply opens Annotate on the previous changeset where ANY LINE in the file was changed. But that is not what was requested. What we need, and what TortoiseBlame does, is to open Annotate on the previous changeset where the SELECTED LINE was changed.
-
Göran Wallgren
commented
* When there are local changes, it's not very useful to see these in the Annotate view. Instead we should see the latest Checked-in changes (at least optionally)...
-
Göran Wallgren
commented
Also, the line that was selected (when requesting the Annotate) should be pre-selected (and scrolled into view) when the Annotate view appears. This is related to the following uservoice:
https://plasticscm.uservoice.com/forums/15467-general/suggestions/3533001-annotate-this-line -
Göran Wallgren
commented
This uservoice is related to this one: https://plasticscm.uservoice.com/forums/15467-general/suggestions/13890972-track-the-evolution-of-a-section-of-code-back-thro
-
Göran Wallgren
commented
Yes, "Annotate previous changeset" is the most important of my suggestions here. It's a must-have feature for any Annotate/Blame implementation... Without it, you can only see the latest revision of a line or block of code, with no quick way to trace it further back into history.
-
Jan
commented
* When right-clicking a changeset/line, add a choice "Annotate previous changeset" (this is so you can trace the earlier history of the line you're interested in).
This is a very important feature for us.
-
Göran Wallgren
commented
OK, didn't see the info bar at the bottom... :P However, the bottom area works fine, except that it should be updated when I move the cursor to a line that comes from another changeset (at least when the cursor is in the left area)! That is, when clicking a changeset line in the left area it becomes selected, but it should also be possible to move the selection with cursor up/down and PgUp/PgDn keys.
-
* Use a tooltip box to display log message (and branch, date etc) when hovering the mouse pointer over a changeset/line.
** DISCARDED - info already displayed in the bottom area. No need to show a tooltip (hard to read since it disappears and hides the underlying code).
-
Thanks Göran,
We appreciate the suggestions.
Yep, good-ol SVN wasn't able to handle branches decently but it made a good job "blaming" :P
We'll discuss this internally and try to implement it.
