Name of the blog

Short description of the blog

Better Merging - Part 2

Following on from Tim Rutter’s article ‘Better Merging – Part 1’, we have looked at how to improve the merging capability of the tool even further by introducing Merge Paths and a Merging perspective for the 2009-1 release (see Stephen Worthington’s blog on perspectives – ‘PureCM gets a complete makeover’). This is especially useful if you have a staging hierarchy, eg. Development, QA, Release. In such a situation, pushing changes to the next level becomes very transparent. There are many benefits from introducing these merging features, here are the key ones:

Centralized location

A new Merging Perspective provides a central location where users can easily see which changesets have been merged between streams as well being able to carry out required merges. From here users can create new merge paths and see all existing ones. A merge path consists of 4 nodes:

Merged Changesets – Here you can see which changes have been merged from the source stream to the destination stream.

Pending Changesets – Changes that have failed the quick merge process will end up here, allowing you to carry out a full merge, resolving any conflicts (see "Better Merging – Part 1" blog). Changesets can be moved here directly, from ‘Unchanged Changesets’ or all changesets could be moved here for certain types of merge paths. We’re going to introduce an option that would force all changes to become pending for the path. So for example if you have created a child stream and you know you want all the changes that will be submitted to the parent then it makes sense to make all the changesets pending.

Unmerged Changesets – All changes that have been submitted to the source stream, but have not yet been merged to the destination stream are shown here, with functionality to carry out the merge, move to pending, or move to excluded.

Excluded Changesets – When a changeset should not be merged to the destination stream, it can be placed here, helping other users to avoid performing unwanted merges.

Creating the Merge Path..

The display name can be edited to provide a friendly name.

Automatic Merging

Automatic merging optionally takes place when changes are submitted to a stream. So for example, if multiple streams exist that are based on one ‘main’ stream, and it is important that these streams are kept up to date with Main, then a merge path could be created for each of these, with the option to ‘automatically  merge’ switched on (ie Main -> Stream1, Main -> Stream2 etc). This would result in the submitted changes being quick merged to the other streams at the time of the submit. If the quick merge fails, due to conflicts, the changesets would then appear under the Merge Path node as a pending change.

When working with automatic merging, Continuous Integration becomes a very useful practice to control code quality, so look out for a future blog on Continuous Integration...

Further usability improvements

We’re well underway in the development of these new features but have plans for more usability features:

Allowing one off merges to take place from the Merge perspective is an idea we are considering – so rather than having to navigate to a stream, or Workspace, you should be able to use the Merging perspective to do any merge. A ‘My Pending Merges’ node will be useful for developers who have submitted a change to a stream and then need to merge to other streams. This will list only their changesets that need merging. An ‘All Pending Merges’ node will be useful for managers or administrators responsible for overall merging to quickly see what needs merging.

We’re always open to suggestions or ideas so if you have any regarding merge paths, or merging in general, please let us know.