Merge: contiguous automatic conflicts produce a non automatic conflict?

A few weeks ago, we received a support ticket showing a pretty specific merge case where our mergetool was prompting the user to resolve a non-automatic conflict. The changes on the source and destination revisions were on separate sets of lines, so at first sight they should be merged automatically. But the changes where contiguous. Let me show you the case:

The files I used are not related to the original question, but the case is the same. The user pointed that p4merge was not detecting conflicts and performing the merge automatically:

So p4merge is making your life a bit easier than Plastic's mergetool by doing some automatic operation for you, right? It's fine for a case like this. But let me show a similar example, this time with code.

Here is p4merge, with changes in separate lines of code on the source and destination and identifying both of them as separate changes. The merge is automatic:

However, looking at the result file, the code there is not likely the intention of neither of the developers. Now let's see how Plastic's mergetool does it: 

In this case, mergetool is again detecting a non automatic conflict, but in this case, this is a better option, since the incorrect automatic result would otherwise remain unnoticed.
This is so because when dealing with code the context is important, and Plastic will check the context of the conflicts to determine if a situation can cause potential "merge pain". On that situation, the rule is "better ask than automatically resolve something potentially dangerous".

New writings available

Check the latest "ALM Tools and Techniques" and there our writing about "Language aware SCM", unveiling some of the root ideas behind the tools we're development.

The first step was Xmerge & Xdiff, then "method history" but the best is still to be delivered :P

Plastic SCM release 3.0.19

In this latest release of Plastic SCM version 3.0.19 we introduced a bunch of new features and bug fixes,
Beside the release notes here, this blog will higlight some of the things we introduced/fixed in this release.
Just in case you haven't downloaded this version yet you can do it here

Let's start with new features:

TEAM CITY CI:

Plastic SCM now integrates with Team City Continues Integration
from JetBrains through our own plug in get it here log in and download the Team City plug in

Mantis integration:

Now we support the latest Mantis 1.2.4

Shell Extension:

Include the annotate view. when right clicking on an item,
users will be able to annotate that item.

Visual Studio integration:

Added support for solution folders.

Check in dialog with task control now allows including recent comments:

When Plastic SCM is configured to work with a task control on task on
changeset mode, the check in dialog now allows including recent
comments, as the usual check in dialog.

Bugs fixed - most important:

Adding items from the GUI in Linux was not working:

This was a Mono issue related to return the focus to the parent window when the Comments
dialog was prompted.

The diff now opens as a separate window when it is called from the merge dialog or the 3D tree:

When diffing items from the merge dialog or the tree, the difftool was opened embedded as a
Plastic SCM view (when this setting was configured this way), which was not usable, since the
difftool was opened behind the dialog.

Branch Explorer:

When the last two changesets on a branch had exactly the same date, the
latest was drawn outside the branch.

Visual Studio integration:

There was a problem when the workspace that contains a solution binded to Plastic SCM was
deleted. Then, when the solution was opened in Visual Studio and the user executed a Refresh Status operation a null was reported.

Add dir + file was not recursive:

Selecting a file and a directory and performing an add operation from
the GUI did not add the directory recursively. Now the user can add recursively or non-recursively when a directory is selected.

Improvements, visible and behind the scene!

Active Directory authentication:

Although in the release notes this is mentioned as a bug, but in fact it is an improvement, Plastic
SCM was directing all the user queries to the central server instead of a remote (local) one if existed. This was causing performance problems since users needed to be resolved.
We where using an older method, now we use a new one GetDomainController method.
You will need to update the server to 3.0.19 to benefit from this improved AD resolution.

Shell Extension:

Performance issues noticed on the Windows Explorer related to external
drives (especially floppy drives) and network mapped drives when the Shell Extension was installed.

Improve search toolbar:

Search boxes in difftool, mergetool, code review and annotate view.
Now not only the buttons are clickable, but also the labels area.

Before

After

Improving some error messages:

The update report message "Can't load root item..." has been improved
to include more information about the causes of the error. In addition to this, if the user clicked on 'retry update' an assert false was
reported.

When diffing identical revisions a message with the caption "Error" was shown, now the caption is "Information".

last but not least view the full release notes for the complete list of improvements and bug fixes in this release here, and we hope you enjoy this one!

DAG rendering - take two

A few days ago I posted about some DAG rendering techniques we’re using in the new Plastic SCM release we’re working on.

Today I’d like to go through the alternative rendering techniques, the pros and cons of each of them, and then try to grab some feedback about which one is better.

Motivation

One of the main consequences of the DVCS age is the huge number of branches repositories have to deal with. Previously SVN, CVS, VSS and others (and I’d include P4 and now TFS in this pack) avoided branching as hell. But now everyone is embracing branching, so a good way to draw an item’s history and parallel evolution is required.

I’ll describe how Mercurial diagrams work (inTortoise Hg 2.0), then will do the same for Git using GitK and GitHub network graphs.

Two rendering styles

There are basically two alternatives right now for displaying version control graph diagrams:

Vertical style: rendering nodes from top to bottom, top being the newest changes

Horizontal style: like the previous rotated 90 degrees clockwise

Mercurial style

Mercurial (Hg) graph rendering uses the vertical style. The graph focuses on “commits” (or changesets/checkins, if you prefer) which are drawn top-down, starting with the more recent ones and going back in time as you scroll down.
The basic elements are displayed in the following picture.



Commits are represented by circles, decorated differently depending on whether they’re simple, tagged, or loaded in the workspace. Each commit can have up to two parents. (In Hg every commit can only have one merge; multiple-merging is not supported.)

One interesting feature here is that branches are “bent” to reuse horizontal space when another branch ends. The graphic tries to be as narrow as possible, shrinking or growing horizontally depending on the number of parallel branches.

The next screenshot shows an actual image of a real repo, taken from the release notes of Tortoise Hg 2.0. I’ve highlighted a merge.



It is important to note that “merge links” are just lines between commits, with no special decoration. Of course, trained developers will immediately find them and recognize their meaning. “Branch terminators”, indicating that a Hg branch has been “closed”, appear as rectangles at the end of a branch.

Git(K) style

Let’s take a look at a GitK screenshot, maybe an overcomplicated one, extracted from http://blog.spearce.org/2007/07/difficult-gitk-graphs.html. Fortunately not all GitK graphcs are this hard to follow!



It’s clear that horizontal space can be wasted if there are too many active parallel development lines (branches) at a given point. I’ve marked a merge and, as with Hg, there are no special symbols to draw merges, just a line between two commits.

It is important to note that Git, unlike Mercurial, is able to handle multiple merges at the same time (a commit can have more than 2 parents).

GitK follows the same “vertical pattern” that Tortoise Hg uses. I find Hg rendering style more polished but I guess it is a matter of taste.

Rotate: enter the GitHub network graph

The GitHub “network graph” follows a more “traditional” rendering approach: branches extend from left to right instead of top to bottom.

It more closely resembles the kind of diagrams that most people draw on a blackboard when trying to explain how a project evolves.



You have to click on the commits to see the related information. This differs from the vertical style, where the comment, committer and date always appear on the right.

As time passes, the graph evolves to the right, with the dates represented like this:

Vertical style – pros & cons

Using a GitK screenshot taken on a Mac OS X machine (see http://effectif.com/git/making-gitk-look-good-on-mac), I’ll summarize the pros & cons of the vertical style. BTW, feel free to send comments/suggestions.

Pros

Scrolling down to move back in time is quite natural since we’re all used to it thanks to similar controls, such as list views. In fact, the entire graph is just a modified list view.

Branch lines are bent (Hg) or moved left (GitK) in order to reduce the graph width as much as possible. Following a branch over time is a simple “vertical trip”; you have to check if the branch moved left or right depending on changes made on other branches.

Cons

These days, most display screens are much wider than they are tall, so the vertical style does not make the best use of the available screen real estate.

When there are many open parallel branches, too many vertical lines make the graph hard to follow.

With GitK, the vertical space is even more constrained, since the graph usually occupies the top half of the overall window. (You can resize, but then you lose the bottom half of the window.)

Colorblind people might easily get lost, depending on the colors (this also applies to the horizontal style)

And some notes:

Merges are not drawn as different parent links, which could make the graph easier to understand. (We took care to do this in the Plastic SCM BranchExplorer.)

There is no specific representation of branches; branches are just rendered as lines between commits. (This is probably a controversial point for DVCS purists, since branches in Git and Hg, while extremely useful, are not as “strong” as they are in other SCM systems. (That is, the important concept is the “commit”, and the branch tends to be secondary. In fact, Hg is able to do “anonymous” branching.)

Horizontal style - pros & cons

The horizontal style is the one I’m more used to, because it’s the one we use (so far) in the Plastic SCM BranchExplorer. It also resembles quite naturally what we normally draw on a blackboard to depict releases, branching patterns on a project, and so on. The following picture shows a hand-made branching (or release) diagram. It seems more natural to draw it this way, because people are more used to graphs in which time is on the horizontal axis than on the vertical axis…

Pros

Better use of modern ”landscape”-style display screens.

More natural, since the graph better resembles blackboard diagrams of branching structures.

Cons

When there are tons of parallel lines (lots of open branches). you might have to scroll down to find your branch.

Conclusion, questions and thoughts

First some questions and thoughts:

None of the Git or Hg tools display “merge links” as such. Do you miss this information? (I ask this because I always draw it manually on the blackboard and we implemented it this way in our BranchExplorer).

I’m not aware of zooming capabilities on GitK or Tortoise Hg to deal with the branching diagram. Do you think it is useful?

Finding the perfect rendering technique seems to be difficult. For instance when repositories are big enough there will always be a ton of branches and commits (changesets), so rendering all of them can make the graphic confusing. One of the things we’re working on is having an option to render “relevant commits only” (only changesets that are involved in a merge or are at the beginning or end of a branch ):

Neither Hg nor Git displays “branches” as such, as elements. What do you think about it? I’m totally biased here towards what we do with the BranchExplorer but I’m more used to the following where branches are depicted as “first class citizens”:


In conclusion: drawing branch diagrams (or release diagrams, if you prefer) is not an easy task, because everything looks great when there are only a few branches and changesets involved, but easily becomes hell with real projects with tons of branching and merging.

Filtering – the ability to temporarily suppress the display of branches you’re not currently interested in – might be the best option to keep things under control .

DAG rendering

If you don’t know what DAG means … lucky you! You’re probably a happy developer focusing on solving your own software problems, instead of delving into nitty-gritty version control details.

But if you’ve been in the coding community for the last 3 years or so, you’ve probably heard of “DAG oriented” distributed version control systems, such as Git. (I won’t include Mercurial here since it is, theoretically, a delta-based system according to the now famous "Getting Git" from Scott Chacon .)

DAG, which stands for “Directed Acyclic Graph”, is the underlying data structure that Git, and other SCMs, use to store the different versions you create.

While the DAG concept applies to the underlying structure, if you diagram the way changesets (“commits” in Git jargon) evolve, you’ll also get a beautiful tree that is… hey, acyclic too!

Painting trees

We’re working hard on the upcoming Plastic SCM 4.0 release, with a bunch of features under consideration -- from core changes to an even better merge to new visual tools, including a new BranchExplorer.

Today I’m going to share some of the concepts we’re using to render the evolution of the repository, the “changeset evolution” (or “commit evolution” if you prefer). This will help you understand the differences from Plastic SCM 3.0 and also illuminate the best way to render DAG-based version history.

It all started here

The diagrams below show some of our ideas for simplifying the display of version history, so that “what you draw on a blackboard to communicate with your colleagues” can become an interactive diagram, our BranchExplorer.



Since a good number of our new users have Git and Mercurial backgrounds, we thought that diagrams like these would make them feel more “at home”. Plastic SCM 4.0 will introduce some of these display strategies, which are similar to those of the most used DVCSs out there.

From paper to pixels – take 0

Here is one of the initial screenshots, similar to the conceptual diagrams above, but now implemented as an interactive graphic.



Zooming out, you can see a wider diagram in “DAG mode” (not a high-quality rendering, though):

Painting labels (or tags)

We’re also playing with some ideas to render labels in a more visible and interactive way than in Plastic SCM 3.0:



In Plastic SCM 4.0, labels will be fully clickable. Wewill also render them in such a way that you get some additional information even before clicking, such as when the same “changeset” has more than one label.

Going distributed

I don’t want to unveil all the details yet, so consider the next two as “spy photos” like the ones that show up on car magazines when a new model is still under development. (You know, you can get most of the details if you look carefully :P)

Right now I’ll just show some alternatives we’re working on with very preliminary screen shots. The following screen shot (which looks quite arcane to me now) includes some of the new labeled-changeset display along with information about different replication sources.



And finally, a much more polished screen shot quite evolved from the previous one (but we’re still not finished with BranchExplorer development!).

Wrapping up

In future posts, coming soon, long-term Plastikers will discover a bunch of forthcoming changes, while newcomers will still be able to see (and comment on!) some alternatives for diagramming repository evolution for a distributed version control system.
Stay tuned.