Flow Image Bar Image Whitespace Image Changes Image Annotate Image

The visualization offers different styles and options to work on it.
Click on the images above to see more.

You can easily grasp the evaluation with the well known flow style
For a better navigation, the visualization offers an bar style.
To evaluate the history, you can select between three options to handle whitespaces.

If your focus is not on programmers, you can use the changes style

Finally you can do a lot more. Especially exploring the dependencies and history of a selected annotation.

As always mentioned the flow visualization is not really new. It can be found in different applications (History Flow and CVSscan). For that, this visualization style is established and well known; the colors indicates the ownership of each line of text or any other information and the corresponding lines are connected in the color of the line from revision to revision. The result is a flow of text lines in the file's history. The information that can be grasped from the flow style depends on the semantic of the color. If this is the ownership, areas of added, deleted and modified lines can be recognized. With one constraint, if the ownership doesn't change due a modification, the modification is not recognizable. The main reason for the visualization to offer the possibility to switch from a ownership view to a changes view and back (see Image #4).

The main benefit of the flow style is that it offers a very good overview over the history with different behavioral patterns that can be easily recognized:

  • Authorship
  • Growth
  • Persistence
  • Concurrence

One disadvantage of the flow style is the difficulty to distinguish the revisions in the history, especially when the view changes from a global overview to a more detailed view. Therefore the visualization offers a second visualization style, the bar style, the second image on the left.

The bar style is a variation of the flow style, the corresponding annotations are not connected.

The user can switch between the two styles any time, so the visualization offers on demand more details or an abstract view.

Not all modifications in the source code are of interest. Some want to differ between changes in instructions and comments, others are not interested in changes in the text's format. The visualization offers a solution for the latter one by offering three options for the whitespace computing in the differ algorithm:

  • Compare all whitespaces: The text files are fully compared. The result matches the stored differences in a line based repository like CVS.
  • Ignore whitespace changes: This option offers a first step in reducing the amount of differences caused by small changes in the text's format. This option works at the moment with a simple compare of the tokens, that can be found in the lines to be compared.
  • Ignore all whitespaces: All whitespaces are ignored in the differ algorithm. Except new lines, since the visualization is line-based. Ignoring the new lines too, would cause additional steps in the differ algorithm and a more complex data model. Therefore it is not yet realized, but could be a challenge for a new release.

Note: If your are interested in a tool that distinguish between changes in instructions and comments or something else, this visualization doesn't fit your needs. Since it is line based, it cannot display the hierarchical structure of code. Nevertheless the differ algorithm could be easily replaced by a algorithm that supports your needs. Take a look at the eclipse package org.eclipse.compare.rangedifferencer, that is used in the visualization's differ algorithm.

The selected way to display changes in the history is shown in the image bellow. On the left hand side, some changes are pointed out that are made in a history. A green frame indicates added lines, a blue frame modified lines and a red frame deleted lines. Since deleted lines can't be found in the deleting revision, the corresponding line range is marked in the previous revision. The second bar style shows the colors used to mark the changes in the visualization while the unchanged areas are gray. The gray color changes from light gray to dark gray if the lines are stable (unchanged) in the newer revisions (like CVSscan does). On the right hand side, the resulting flow image is shown.

How changes are shown

Note: The changes image above shows tiny lines inside the flow. This can be avoided by the use of anti-aliasing. Dependent on the operating system, anti-aliasing can be used in eclipse to draw the images softer. If it is supported you can switch it on and off in the preferences.

In the visualization, you have different options to show the dependencies of the currently selected annotation and revision. The options are shown in the context menu and the image view's pull-down menu.

The context menue

The three dependencies of annotations in the visualization to work on are:

Annotations Dependencies
  • A: Annotations with identical revision as source.
    All annotations that are collateral changes by the author of the selected lines are pointed out.
  • B: The history of the selected annotation.
    Shows where the lines of code can be found in earlier revisions.
  • C: The future of the selected annotation.
    Shows where the lines of code can be found in later revisions.

To support the navigation on the image, the selection of annotations can be changed with the arrow keys. The new selection is made by following rules based on the current selected annotation:

  • No additional key pressed:
    No restrictions are made. The direct neighbor (counted by lines) is selected.
  • The control key is pressed:
    The annotations have to follow one of the 3 dependencies noted above.
    • Vertical: The nearest annotation with the identical revision as source is selected (dependency A).
    • Horizontal: The first line range in the preceding or following revision that contains all lines unchanged or a part of it is selected. (dependencies B and C).
  • The shift key is pressed:
    The annotations have to have the same programmer as author. This enables a navigation on the visualization with one author in focus.