Sometimes you need to know not only what lines have changed, but also who exactly changed specific lines in a file. That's when the→ command, sometimes also referred to as annotate command comes in handy.
This command lists, for every line in a file, the author and the revision the line was changed.
If you're not interested in changes from earlier revisions you can set the revision from which the blame should start. Set this to
if you want the blame for every revision.
By default the blame file is viewed using TortoiseBlame, which highlights the different revisions to make it easier to read. If you wish to print or edit the blame file, select Use Text viewer to view blames.
You can specify the way that line ending and whitespace changes are handled. These options are described in the section called “Line-end and Whitespace Options”. The default behaviour is to treat all whitespace and line-end differences as real changes, but if you want to ignore an indentation change and find the original author, you can choose an appropriate option here.
You can include merge information as well if you wish, although this option can take considerably longer to retrieve from the server. When lines are merged from another source, the blame information shows the revision the change was made in the original source as well as the revision when it was merged into this file.
Once you pressTortoiseSVN starts retrieving the data to create the blame file. Once the blame process has finished the result is written into a temporary file and you can view the results.
TortoiseBlame, which is included with TortoiseSVN, makes the blame file easier to read. When you hover the mouse over a line in the blame info column, all lines with the same revision are shown with a darker background. Lines from other revisions which were changed by the same author are shown with a light background. The colouring may not work as clearly if you have your display set to 256 colour mode.
If you left click on a line, all lines with the same revision are highlighted, and lines from other revisions by the same author are highlighted in a lighter colour. This highlighting is sticky, allowing you to move the mouse without losing the highlights. Click on that revision again to turn off highlighting.
The revision comments (log message) are shown in a hint box whenever the mouse hovers over the blame info column. If you want to copy the log message for that revision, use the context menu which appears when you right click on the blame info column.
You can search within the Blame report using→ . This allows you to search for revision numbers, authors and the content of the file itself. Log messages are not included in the search - you should use the Log Dialog to search those.
You can also jump to a specific line number using→ .
When the mouse is over the blame info columns, a context menu is available which helps with comparing revisions and examining history, using the revision number of the line under the mouse as a reference.→ generates a blame report for the same file, but using the previous revision as the upper limit. This gives you the blame report for the state of the file just before the line you are looking at was last changed. → starts your diff viewer, showing you what changed in the referenced revision. → displays the revision log dialog starting with the referenced revision.
If you need a better visual indicator of where the oldest and newest changes are, select→ . This will use a colour gradient to show newer lines in red and older lines in blue. The default colouring is quite light, but you can change it using the TortoiseBlame settings.
If you are using Merge Tracking and you requested merge info when starting the blame, merged lines are shown slightly differently. Where a line has changed as a result of merging from another path, TortoiseBlame will show the revision and author of the last change in the original file rather than the revision where the merge took place. These lines are indicated by showing the revision and author in italics. The revision where the merge took place is shown separately in the tooltip when you hover the mouse over the blame info columns. If you do not want merged lines shown in this way, uncheck the Include merge info checkbox when starting the blame.
If you want to see the paths involved in the merge, select→ . This shows the path where the line was last changed, excluding changes resulting from a merge.
The revision shown in the blame information represents the last revision where the content of that line changed. If the file was created by copying another file, then until you change a line, its blame revision will show the last change in the original source file, not the revision where the copy was made. This also applies to the paths shown with merge info. The path shows the repository location where the last change was made to that line.
The settings for TortoiseBlame can be accessed using the section called “TortoiseBlame Settings”.→ on the TortoiseBlame tab. Refer to
One of the limitations of the Blame report is that it only shows the file as it was in a particular revision, and the last person to change each line. Sometimes you want to know what change was made, as well as who made it. If you right click on a line in TortoiseBlame you have a context menu item to show the changes made in that revision. But if you want to see the changes and the blame information simultaneously then you need a combination of the diff and blame reports.
The revision log dialog includes several options which allow you to do this.
In the top pane, select 2 revisions, then select→ . This will fetch the blame data for the 2 revisions, then use the diff viewer to compare the two blame files.
Select one revision in the top pane, then pick one file in the bottom pane and select→ . This will fetch the blame data for the selected revision and the previous revision, then use the diff viewer to compare the two blame files.
Show the log for a single file, and in the top pane, select a single revision, then select→ . This will fetch the blame data for the selected revision, and for the file in the working BASE, then use the diff viewer to compare the two blame files.