Name of the blog

Short description of the blog

Modular Software and Version Control


There are many issues to consider when deciding how to structure your software from an architectural point of view. Chances are that you’ve already split up your code into several modules or components to separate the various routines.

However, deciding about the best software design isn’t the purpose of this blog. At PureCM, we like to look at software from a version control point of view. So let’s agree for the purpose of this blog that a component is a set of files and folders that are versioned together. This also means we’re looking at code components, and at referencing compiled DLLs or the like.

To modularise or not to modularise…

Remember, we’re looking at this question from a version control point of view. So basically there are two options: consider project as one module, or having many modules that are developed individually.

The advantage of having one module for the whole project is obvious. The project gets always built and versioned as a whole, while release snapshots are also taken from version branches as a whole. Also, creating a workspace for a version or feature would always populate the developer workspace with the full content:

Simple. So why would we want to have separate modules?

One of the main reasons is that you might want to reuse certain modules or components for other projects, that they might suddenly get their dedicated developer (team) and individual release cycles. As a consequence, these components need their own container in order to version them separately from the projects they are linked to.

Shared components – an example

Let’s assume you’re using your icon component across multiple projects, with only a specific group working on them – I’ll call them ‘magic designers’. They are the only ones working on these files, so don’t really need to get the other project content to make their changes.

In such a case, you can give them their own version branch in PureCM, which only contains the ‘icons’ components files and folders. Any of your projects using that component could then link to that component version.

So now your developers can either create a workspace for the relevant project version/feature, or the shared component only.


Sharing component releases or all changes immediately?

Using shared components in PureCM also gives you another option. You can choose whether you want to share a static component release or dynamic component version.

The obvious advantage of sharing component releases is that changes made against the component version aren’t shared until t ested and ‘released’ as a release snapshot. A development manager would then simply update the component link to the latest component release to update his project. Of course, this also assures that you can link your projects to different component versions as needs dictate.

O n the other hand, there are cases when you’d want to immediately reflect changes made to a component across all linked location. Linking to the component version allows you to do so. Of course, even with this solution you can have your ‘magic designers’ group work on multiple component versions without problems.


Which of the discussed option you choose is down to your needs; the following t able summarises the available options in PureCM:


Only share stable component updates

Share component updates immediately

Support one component version only

Link to relevant component release

Link to component version

Support multiple component versions

Link to component release of the relevant version

Link to relevant component version

However, as a development manager you can be sure that PureCM tracks all your changes across all linked locations:  any changes made to the component, when a component was linked to which project, at what point the link was updated to a newer component release etc.

If you work with PureCM Professional and use tasks, you will get even more information. PureCM will show all tasks originally completed against a component in the history view of any linked location - and the other way around. Not bad to facilitate release note creation (and have a full, repository-wide task history)!

If you want to learn more about working with shared components, there’s also a white paper available. It covers the above and component setup in more detail. Just download it from here:


SDC, Part 13: Rescheduling (and the consequences for work in progress)

Tim has already described how to schedule tasks and features in Part 3 of the series. This blog will build on this to show how you can reschedule a task or feature. This is one of the major benefits to using features – you can choose which version the feature will be completed in. 

For example you might start a feature in Version 1 thinking it will only take a week. The developer working on the feature will submit changes to the feature. If you realize it will take longer than expected you can move the feature to Version 2. Because the developer only submitted changes to the feature, Version 1 was never updated.

Rescheduling Tasks and Features

To reschedule tasks and features, select them in the Projects view and select ‘Move’. This will launch a dialog for you to select the new version. Alternatively you can drag-and-drop them into the version within the Projects tree.

You are not restricted to moving tasks and features between versions. You can move them between features and folders in the same way.

If developers have not started working on the task or feature then this is it. If work has already commenced then the situation becomes a little more complicated... but less so than you might expect!

Work In Progress: Tasks

A developer is working on the task within her workspace so the task appears under Current Tasks with the file changes.

If a manager moves this task to another version the developer will receive a warning that the task has been moved.

When the developer goes to the My Tasks view, she will see that the task is still assigned to her but that it is not currently being worked on.

The developer will press ‘Start’ to begin working on the task and select the existing workspace. This will switch the workspace to the new version while keeping the changes made.

If you are using a release of PureCM prior to 2010-1d you will first need to manually shelve your changes to the server and revert the changes from the original workspace. You will not be able to switch a workspace which contains changes. After switching the workspace you will need to unshelve the changes back into the workspace.

The simplicity of this approach is often overlooked. Before we started using tasks the team leader would tell each developer which version to submit the changes into. So it was the responsibility of the developer to ensure they were working against the correct version. This is both prone to error and time consuming. Now PureCM switches the workspace to the correct version automatically.

Work In Progress: Features

Now, let’s look at the case when a developer has already submitted changes to the feature. PureCM will automatically create a new feature stream from the new version and merge all the changes from the old feature stream into the new feature stream. If the files in which the changes were made are identical between the two versions then this will all happen automatically. If any of the files are different then this will create an update conflict.

If you are using a release of PureCM prior to 2010-1d you will need to create a new feature from the new version. Create a merge rule from the old feature stream to the new feature stream with the auto-merge flag set. Complete the old feature and set the owner for the new feature.

Update conflicts appear in the My Tasks view if you own the feature.

Click on the Resolve button to launch the Changeset Dialog and resolve any conflicts.

In Summary

This blog has described how to reschedule tasks and features and how developers can switch their changes to the new version.

  • Moving tasks and features in the Projects view is trivial.
  • If a developer is working on a task in a workspace then PureCM will switch the workspace to the new version.
  • If a developer has submitt ed changes to the feature then these changes will be merged to the new feature stream.
  • Moving a feature may create update conflicts which can be resolved within the My Tasks view.
We'll now make a pause in our blog series, look at feedback we get from our readers, and then start filling the gaps. Any comments about topics you'd like to see here are highly welcome!

SDC, Part 11: Fixing a bug on a live release

In this blog we will look at how to use PureCM in the process of fixing a bug in a live release. As a developer will probably already be working on 'the next release' it is important that switching to a previous release (to fix a bug) is as uncomplicated as possible.

PureCM provides the mechanism for a developer to work on a fix for an old version, and create a new release, without affecting his current development environment – or have his current development environment affect the bug fix environment (parallel development) … So how does it work?

Raise the task

The first stage is to raise a new task on the specific version of the project. A developer can then simply go to his 'My Tasks' view and click on the 'Start' button to populate his workspace with the code of the relevant version. This will avoid inclusion of any new changes that have gone into subsequent versions.

We've already covered how to create a new task, assign it to a developer and start work on it. So assuming that is all in place, the next step is to actually fix the bug.

Annotated File History

This is a good time to highlight an older feature of PureCM that proves very handy in the process of investigating and fixing bugs.. 

We will assume that the developer has debugged the release and managed to isolate the code that is causing the bug. If it is not an obvious bug, then in order to establish if the code was deliberate or just to find out why it was written, then using the annotated history can help…

This provides a quick way of navigating to the changeset that the code was implemented with thus providing the developer with the description, and if this is not enough to make a judgment on how to proceed then the changeset also provides the name of the developer who made the change – a short conversation could clear things up! As well as 'why' the change was made, it could also be useful to know 'when' the change was made in case an older release needs to be fixed.

Now the bug is fixed, the developer has completed some local testing and is keen to get this fix to the customer as soon as possible, therefore a new release is required. Clicking the 'New Release' option on the Version performs this task.

Tim's blog on creating a release has covered the details for this and how to deploy the release files to another machine, typically to build it.

Merging the change into relevant versions

The last stage in this process is to ensure the fix finds its way into other relevant development versions. This can be achieved by using PureCM's merging capability, even automatically using the 'Merge Rules' functionality. 'Merge Rules' will be described in detail later on in the SDC blog series.

So assuming merging is not done automatically, the owner of the target version can manually perform the relevant merges by navigating to 'My Tasks' where any Pending Changes (per version) will be listed ..

Here, I'm the owner of 'Version 2'. Pressing the 'Show' button reveals the list of changesets pending merge into this version. Right click the relevant changeset and choose 'Merge Change' (or 'Exclude' if you don't need this change).

In Summary

Fixing a bug on a live release can be achieved quickly using PureCM ..

  • Create a task specific to the version
  • Use Annotated History to understand the reasons and history of a change
  • Create new release based on the fixed version using the 'Create Release' functionality.
  • Ensure the fix is merged to the relevant Versions using PureCM's merging functionality.

The next blog will look at merging and merge rules in more detail.

SDC, Part 7: Working on a Larger Work Item: Features

In the last blog Tim described how a developer works with tasks to complete small units of work. I will follow on from this to discuss how a developer works with larger pieces of work.

My Features

We have already introduced the concept of a feature and described when a manager should create a feature as opposed to a task. So lets assume a manager has already assigned a feature to you.

After a feature has been assigned to you it will appear in the ‘Workspaces’ view under ‘My Features’.

From here you can:

  • Open a workspace for the feature. This will allow you select an existing workspace or create a new workspace.
  • Show the file differences between the feature and the version.
  • Complete the feature by merging all the changes back into the version.


Feature Workspaces

To start working on the feature press Open and select an existing workspace or create a new workspace. If you have already created a workspace for a feature which you have completed then you should select this workspace. This will switch the workspace from the old feature to the new feature. Switching a workspace is a lot quicker than creating a new workspace.

After opening the workspace you can start working on the files the same as if you were working against the version directly. You can use any of the PureCM clients or one of our IDE plugins such as Visual Studio or Eclipse.

The difference between working on a feature, rather than working on the version directly, is that submitted changes are only applied to the feature. So you can checkpoint your work, submitting unfinished changes, without breaking everybody else’s workspace.

Completing the Feature

When you have submitted all the changes required for a feature it is time to complete the feature and merge the changes back into the version. In the Workspaces view press Complete.

This will open the Changeset Dialog showing all the changes for this feature.

Press the Submit button to apply these changes to the version. All the feature changes will be merged back into the version as one changeset.

Features & Tasks

If you are using features and tasks then you start working by selecting Start on the task in the My Tasks view, as described in Tim’s blog. Whether the task is part of a feature or version makes no difference when working with tasks; PureCM will automatically populate your workspace with the correct files and folders.

When all the tasks within a feature have been completed, the feature will appear under ‘Pending Features’ in the My Tasks view. From here you can Complete the feature to merge it back into the version. The feature will only appear under ‘Pending Features’ if the feature is assigned to you.

In Summary

  • You can create a new workspace or switch an existing workspace to start working on the feature.
  • You can checkpoint your code within a feature workspace without breaking everybody else’s workspace.
  • After submitting all the changes to the feature you complete the feature by merging all the changes back into the version as a single changeset.
  • When working with tasks, it makes no difference whether you are working on a feature task or a version task.

The next blog will describe how you can use features to perform code reviews.

SDC, Part 4: Branching patterns


So far, we’ve covered the new planning functionality of PureCM Professional. You’ve seen how to define project and versions and how to schedule and assign work items using features and tasks.


Is this series going to be all about release planning?

So all about project management and nothing on software configuration management (SCM), the traditional core of PureCM. Clearly not! PureCM 2010 fully integrates release planning and configuration management, offering important benefits to the user:

  • In smaller companies, planning and configuration management is often looked after by the same person. In this case, using PureCM 2010 results in much simpler administration and less overhead
  • If planning and CM is done by different persons, PureCM 2010 allows for an easier collaboration and real-time project status updates for both sides
  • Developers only need one tool to manage their work items and complete them, which again reduces overhead


How does planning relate to configuration management?

First, a quick refresher about glossary. PureCM uses the concept of stream-based branching. This allows changes being automatically inherited between streams, making streams something like next generation branches. However, to facilitate our discussion, I’ll simply use the word ‘branch’ in this blog.

To understand the link between planning and CM, let me put the two sides next to each other. When planning your releases by creating versions and scheduling tasks using the Projects view, PureCM automatically prepares a branch for every new version. This is visualised in the diagram below; on the left is what you create using the Projects view, and on the right is what PureCM does for you in the background.

The word ‘prepare’ is important here, as the branch only gets created when the first user starts work on it, i.e. the first workspace is based on this version. So when the first task is worked on, the branch is created from the head revision at that point in time. The advantage here is that you can already start scheduling for the next version without separate branches, so no merging is needed until work has started on both versions. Once work has started, you’re automatically able to work in parallel.

What’s important is that PureCM automatically tracks and notifies the version owner(s) about changes present in one version but not a related one. Which notifications owners receive can be customised by adding or modifying merge rules between versions. You can imagine that notifying owners about pending merges and tracking them after completion reduces human error and facilitates parallel development enormously. I’ll not go into details here, as merge rules will be covered separately.

Of course, you can customise branch creation as long as work hasn’t started on a version. Say you want to link a new version to the same branch as a previous version. This is useful if you only want to separate versions for scheduling, but submit changes against the same branch, the latter becoming your development mainline. This would look as follows:

So a project and configuration manger can sit together when planning a release and collaboratively decide on the best approach. Note that you can also hide versions from the projects view once they don’t need to be supported anymore. This keeps the Projects view tidy and makes it easy to navigate when scheduling and tracking progress.


...and how do features work?

When scheduling a feature in PureCM, the tool also prepares a branch, just as with versions. However, features are typically used in a different way than versions: versions tend to be longer lived, and you only merge selected changes between versions. On the other hand, features tend to be short-lived and will get fully integrated back into their parent version. This is shown on the next image (release snapshots are omitted for simplicity).

By listing incomplete features as children of the version they’re scheduled against, managers get an instant feedback about work in progress, while developers can easily define tasks for a feature to split up their work. Any feature in progress won’t be included when building the version. To get an overview of all completed features, tasks and release snapshots of a specific version, right-click on the version and select ‘Show Submitted Tasks and Releases’.

The big advantage working with PureCM features comes from the fact that it uses stream-based branching. Therefore, a feature automatically inherits all changes that are submitted against its parent version. This is explained in one of Stephen's earlier blogs. You can turn this off again by changing the merge rules, but we've never seen anybody doing this after realising the benefits... Note that working with features also allows for powerful code reviews before integrating the feature. 

We'll revisit features from a developer perspective in a later blog of this SDC series to discuss how they can best work with features.



This blog has focused on the benefits you get by working with an integrated release planning and CM solution. Parallel maintenance and development can be automated and thus managed with little overhead.

Let’s revisit the main issues I covered in this blog:

  • Project and development managers can collaborate in the ‘Projects’ view when planning their releases and customising their configuration management
  • Versions prepare a branch as a default and support automated notifications about pending merges
  • Features prepare a branch as a default and are automatically kept up to date for easy integration once completed
  • Configuration managers can customise and combine the use of versions and features, e.g. using multiple versions to assure maintenance on more than one release

So far, this blog series has focused on the manager’s perspective when setting up the basics of the development lifecycle. Starting with the next blog, we’ll change hats and discuss how developers can benefit when working with tasks and features.


Continuous Integration with Feature Streams

The 2010/1 release of PureCM was packed full with so many new features that it is easy to overlook some of the more important ones. So I wanted to focus on one of the new features I am really excited about – features.

Working with Features


To create a feature in PureCM open the Projects view, right-click a version and select ‘New Feature’.  From here you will specify the name of the feature and a description. You can see a video of this on the PureCM website.

To start working on the feature go to the My Workspaces view and select ‘Add Workspace’. You can select the feature from the Projects tab.

If you already have a workspace you can switch it to the new feature by selecting ‘Switch’ in the My Workspaces view. This will be very quick and will only change the files which are different.

This has created a new stream for the feature. So you can submit in this workspace without changing the version stream. This is great for checkpointing your code where you can submit incomplete/untested code without breaking everybody else’s workspace.

Having used features for a few months now this has really changed the way I work. I now submit every hour or so. This allows me to try something different safe in the knowledge that I can get back to my previous checkpoint if it doesn’t work out. After completing a piece of work I can also go to one of our testing machines, create/switch a workspace for the feature stream and run the acceptance tests. Only if the acceptance tests pass will I merge the feature changes back into version stream. And I have become more productive because while the acceptance tests are being run on the testing machine I can start working on my next feature.

When I am ready to merge all the feature changes back into the version stream I go to the My Tasks view. The feature is listed under ‘Pending Features’ and I can select ‘Complete’. 



This will launch the changeset dialog where I can review the edits and submit them as one changeset back into the version. The feature will also be complete – so will no longer appear in the Projects view.


Continuous Integration and Feature Streams


The simplicity of working with feature streams hides a very powerful aspect to PureCM features – they keep themselves up to date with the version stream. When another developer submits changes to the version stream the changes are automatically merged into your feature stream. So all you have to do is update your workspace.

So you get the best of both worlds. The changes you are making are isolated from other developers, so you can checkpoint your code. But the changes other developers make are being pulled into your feature.

The other advantage with keeping your feature up to date with the version is that merging the feature changes back into the version is trivial. You have already merged the version changes into the feature, so merging the feature changes back into the version is simply a matter of copying the files across.

There are occasions where another developer will submit changes to a file which you have already changed in your feature. This will create an update conflict which will appear in My Tasks and My Workspaces.


You can press ‘Resolve’ to launch the Resolve Tool to resolve the conflicts and merge the changeset into the feature.

Guidelines for using Features

As a rule of thumb we recommend you create a feature for any piece of work which takes longer than half a day.

·        Create a new feature

·        Shelve and revert your current changes

·        Switch the workspace to the feature

·        Unshelve the changes into the feature workspace

We are already working on making this process automatic.

Features do not support file locking. So if you cannot allow multiple developers to work on the same files concurrently then features are not appropriate. Cross-stream file locking is something we are hoping to implement for the 2010/2 release.


If a feature takes longer than a week then we recommend you perform interim submits back to the version. You can do this in the Project view by right-clicking the feature and selecting ‘Administration | Merged’. This will merge the changes without completing the feature. It is important not to isolate your feature changes from the version for too long if you want to practice continuous integration.

To get the full benefits of features you will need a Professional License. The Standard License will alow you create features but the features will not automatically keep up to date with the version.

Using tasks you can streamline the process of creating and working with features. Please refer to the PureCM Admin Guide for a full explanation of tasks and how they relate to features.



PureCM 2009-1 Preview

Before we talk features

The first blog in the new year, so first of all my best wishes for 2009! Let me use this fresh start to give you a summarised outlook on PureCM 2009-1, our next major release coming with some rather big changes. So now you might expect a huge list with all the main features, but allow me to make a small detour before getting there...

How you would like to look at your data

If you look at your file system, your data is organised in folders and files. Typically, the highest level folder separates your projects. This is also the approach used by most source control tools such as VSS, SVN or Perforce to structure data in their database. You make changes to a copy of your files or folders, and they get sent back to the database and stored as a new revision.

PureCM uses an additional high level object that includes the files and folders of a project: streams. Streams have two major advantages. First, they remember the relationship between each other, making merging (and merge tracking!) much more transparent. Second, they allow for so called “cheap” snapshots, i.e. branching without making file copies. This allows you to setup your configuration for parallel development, increasing productivity.

Depending on the complexity of your shop, you can create as many (or little) streams as you wish to separate projects, teams, development from maintenance etc... All projects –organised in streams – are stored in the PureCM repository database to keep it safe. You can find some examples later in this blog [anchor].

As a development manager, you need to have all information about your projects at hand. You want to know which changes have gone into a project, which bugfixes need to be merged, or where you are including a specific version of a shared library. So the first big change in PureCM 2009-1 is its repository-centric GUI. To structure the large amount of information present in a repository, the new task-specific views filter the information you need to speed up navigation.

NEW: Task-specific GUI views

As a developer, getting your own sandbox to work on a task in isolation is one of the main views you need, so this is what you get with PureCM 2009-1: the project files and folders, as well as your current changes and all submitted changes to the stream your current workspace is based on. You can thus organise your own changes into changesets, and track the submitted changes from your colleagues you need to integrate.

Note the navigation bar just below the menu bar, which gives you quick access to all the task-specific views. Say you are required to switch to an urgent bugfix and would like to get an overview of your workspaces in this repository, just click on “Workspaces” and select or create the appropriate one.

Likewise, go to the “Streams” view to browse the server, branch your project, and create a release or a stable baseline. You can find out more details about the advantages of the task-specific views in this blog.

Once you have finished a task and would like to move your workspace to the next project or baseline, another new feature in 2009-1 helps you to do this easily: Workspace Rebasing. This feature automatically populates your workspace with the content of any stream you select. No need to delete the existing workspace and create a new one anymore.

NEW: Merge paths for parallel development

Talking of streams actually brings us back to the above discussion about the project structure of a PureCM repository. According to the complexity of your projects, your repository might resemble one of the following (stylised) examples:

In example A, the streams remain typically the same and changes get merged (or promoted) from development to QA to Production. Example B shows a mainline development example with release snapshots, while example C extends the former to a multi-product setup with shared libraries.

You can immediately see that you can use stream folders to organise your streams (or codelines). In this way, you can define permissions on the folder level that get inherited by the streams. This would allow you to define release streams as read only or editable, i.e. used as labels or maintenance branches. In other words, any stream will evolve in isolation or stay static after creation, depending on the stream (folder) policy.

With the new 2009-1 release, you will be able to define Merge Paths between any two streams to track and merge changes in real time. Say you know that you want to keep track of differences between “Feature A” and “Mainline”. Create a Merge Path and you will be able to see at any time, which changes are present in one stream but not in the other, just as in the screenshot below.

This information is also visible in the "Streams" view to highlight pending merges in your stream hierarchy. After merging, the changes get moved to the “Merged changesets” node to track them. Note that all that happens directly on the server, without the need to create a workspace for merging (but you could of course choose to do so as an option).

Using merge paths, you will even be able to define automatic merges! This basically means that any change submitted to the base stream gets instantly merged into the destination stream. In case of conflicts, PureCM automatically moves the change to “Pending Changesets” to allow you to resolve the conflict manually. Of course, one can still choose to make a one-off merge directly on the changeset without defining a merge path.

Feature summary

The essence of the PureCM 2009-1 release is its focus on making work with multiple projects easier. It will not just be easier to work with parallel configurations using Merge Paths and Workspace Rebasing, but also to get the relevant information with the new task-specific views. But before I forget: PureCM obviously gives you more than just that, including advantages like:-

  • Eclipse and Visual Studio integration
  • Proxy Server for distributed teams
  • CruiseControl.NET and FinalBuilder integration
  • Shared libraries between projects (called “Components” in PureCM)
  • Integrated issue management
  • .NET/Java APIs

We will shortly publish the PureCM 2009-1 beta2, which I will certainly announce in this blog. I look forward to getting your feedback once you have been able to play around with it!


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.


Better Merging - Part 1

One of the great strengths of PureCM has always been it's support for parallel development. PureCM's merge functionality allows you to keep track of your changesets and which streams they have been submitted against while making it easy for you to merge these changes into other streams as desired. Now we are looking at making merging even more powerful and simple, but let's first take a look at how merging works today.

Merging Today

The original merge process required you to own a workspace for the stream you are merging into. This gives you a number of benefits such as the ability to easily test each change before submitting it to the server. This is shown as (B) in the lower half of the picture below.

However this process can be time consuming and is hard for manager who may not always have a workspace for each stream. This led to a solution that allows users to quickly merge changes between similar streams, which we called “quick merge”. This allows you to merge changes directly on the server removing the need for a workspace in these situations (A in the picture above).

So far, quick merge will only merge changes where there is no possibility of a conflict. This works well for merging last minute fixes into a release stream or early on in the development cycle when not much has changed in the new development stream but we felt there was a need to improve on this restriction.

Moving Forward

The next stage in this evolution is to allow you to resolve conflicts as part of quick merge without the need for a workspace. This will simply launch the familiar PureCM resolve tool when quick merge finds a conflict.

Combining this new functionality with automated test and build processes (such as PureCM's Cruise Control plug-in) provides a fast and simple way to keep your streams up to date while giving you the security that any errors are picked up immediately so you can assign someone to look at it.

This new advancement to quick merge opens up a realm of possible future features for the tool to help speed up your development process through merging. One example of this is the creation of automatic merge paths to control the flow of your changes through your development streams. Plenty of reasons to look forward to the 2009-1 release – and keep your eyes open for future blogs for information about where we go from here!