The New Merge Client - Additional Information

Additional Information about CollabNet Merge Client

Hopefully you have already read the overview of the CollabNet Merge Client. That was a long document, covering the essential features of the client and the merge process. There are a number of additional features that have been implemented that deserve to be pointed out.

Multiple Targets

The CollabNet Merge option supports multiple targets. As an example, Subclipse is made up of six core projects with a handful of others related to the packaging. Currently, if I want to merge changes from Subclipse trunk to a release branch I have to do the merges one by one for each project. With the CollabNet Merge client I can now just select all six projects and merge them at once.

Under the covers the merge client simply takes your requested merge inputs and executes them once for each selection. Nonetheless, this is a big time saver and simplifies the process. Handling the inputs when merging multiple projects is tricky. So the UI gives you some options about how to transform the path names as well as give you a hint as to what the resulting path is going to be. In this example, the Subclipse repository used a model of /trunk/project so we need to perform the merge using a path that is relative to the source path you enter. If you have a /project/trunk model then you would not. For example, here is an example, where a change from trunk is being merged to several release branches.

As part of making this change, we also have enhanced Subclipse to provide better multi-project support across the board. So, as an example, I can also easily select these six projects and switch them all to another branch.

History View

One of the very nice features of merge tracking is that the History can now tell you when certain commits involved a merge as well as what revisions were merged. We enhanced the Subclipse History view to show this information. If you would like to see this option when browsing history just open the view drop-down menu and turn on the "Include merged revisions" option. This causes the Subversion history API to include information about the revisions that were merged. Subclipse adds a column to the History view to show those revisions.

If you want to see the details of those revisions, possibly including merges that were merged into those revisions, simply select one of these revisions, right-click and choose the "Show Merged Revisions" option. That will bring up the following dialog:

This dialog allows you to see more details about each of the revisions that were merged. If any of those revisions were the result of merges, the list expands out indefinitely to show all of the changes.

Blame/Annotate

In addition the History view, the blame/annotate option is now merge tracking aware. This means when you view the annotations for a file that has had merges performed, instead of seeing the line annotated with the revision where the change was merged, you see the original revision, author and log message where the line was edited. Unlike the History view, this is not currently an option you can control -- it just always does this. The reason was that this option does not currently present any UI before it runs where we could ask what you wanted to do. Most likely we will make this a preference, but until we decide it will just always show the merged revisions in place of the originals.

This file is the same one shown in the History view above. As that screenshot shows in r17 this file was merged. When viewing the annotation, I can see that the lines of code were actually added in r13 including the original author, date and comment. Generally, this is more useful than knowing the revision it was merged. Especially since the commit comment will typically be related to the merge, not the change that was made.