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:


Comment on our product roadmap!

Looking into 2010 from a PureCM point of view

Exciting times are ahead with the PureCM 2010-1 beta now available for download and the full release coming closer. As this release will mark a very substantial step forward regarding PureCM's feature set, it looks like this is a great moment to share our product roadmap with you.

Please feel free to comment; regardless of whether you want to praise or criticise! 


Target release


Release planning, task tracking

  • Agile release planning for multiple projects using releases and iterations
  • Support product backlogs and drag & drop scheduling
  • Link configuration management to release planning
  • Support real-time status updates
  • Support visual reporting with burndown charts
  • Support attachments and comments for tasks
  • Support for multiple task types











Configuration management

  • Visually show release a change has been introduced, e.g. a change or bug fix
  • Improve resolve dialogue for easier copy & paste







  • Support working on tasks in Visual Studio
  • Support working on tasks in Eclipse
  • Support changeset references to Gemini issues
  • Add full integration to Gemini to provide a web front end and helpdesk integration







DB Backend

  • Support SQLite as embedded and cross-platform database backend
  • Support SQL Server databases







Here it is - the PureCM 2009-1 Beta

This update is to highlight that the download links below now point to the latest 2009-1 RC build.


New features

PureCM 2009-1 comes with two major enhancements:

  • Live merge tracking. This powerful feature gives you live and instant transparency about which changes need merging between two streams. Whether you want to push a bug fix back into the development stream or integrate a number of feature streams into your mainline, you can perform all operations directly on your stream without the need to create a workspace. After that, all merges are tracked for full transparency.
  • Task-centric GUI. As a developer, you spend 90% of your time in your workspace. As a manager, your focus is on the project stream. The new task-centric GUI gives you exactly the information you need for your task – not less, and not more.

Further 2009-1 enhancements supporting parallel and distributed development:

  • Workspace Rebasing. Easily switch the content of your workspace to any stream, be it a branch or a snapshot.
  • Deployment Service. Automatically transfer changes to your production environment without installing a PureCM client.
  • PureCM Components. Share libraries across projects to keep them in sync and control change with repository-wide file locking.

Click here to find a more detailed overview about PureCM 2009-1.

How do I best install the PureCM 2009-1 beta?

Note that you need to install both the server and client components of the PureCM beta to test the new features. Depending on your current use of PureCM, you might want to choose one of the following options.

Your current situation

Possible PureCM setup

Download links

I am new to PureCM and have no PureCM components installed yet.

Get the PureCM server and client installer for your OS and follow the on-screen instructions.



Combined client and server

Client installer

Server installer

Eclipse plugin


I am currently evaluating an older version of PureCM, but do not use PureCM for production.

Note that only one version of PureCM can be installed at any one time on a machine. You can thus choose to install the PureCM beta on a clean machine or uninstall your current PureCM version and replace it with the beta.




Please use the links above.

I am already using PureCM for production.

Option 1: You install the PureCM server on a clean machine for testing purposes. Download the .ZIP beta client and run it alongside your current production client when testing (no installation of beta client needed)



Client ZIP

The ZIP client can only be used if you already have a PureCM client installed on your machine.


Please use the links above to download the server component(s).


Option 2: You install both the PureCM server and client on a clean machine for testing purposes.



Please use the links above.


The system requirements are identical to previous PureCM releases and can be found here.  Note that this is a beta product. We would therefore advice that you do not use it on production data.


We are highly interested in getting your feedback, both the good and the bad. This allows us to tailor PureCM’s features to your needs and fix bugs that might have escaped our internal testing. Please send any comment or bug report to, or comment this blog directly. Thank you for your valuable feedback! 


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!


PureCM gets a complete makeover

Why we tackled the GUI

The PureCM GUI is used to perform many different tasks. For example:

  • Developers write and submit code
  • Merge Managers/Integrators merge changesets between streams
  • Testers raise issues
  • Project Managers view reports and check on the status of a project

Feedback from our customers has shown that the current GUI works well in small organisations where the same user performs multiple or all of these tasks. In larger organisations where one user typically performs one task the current GUI does it all – but is unnecessarily complicated.

For the 2009/1 release we wanted to change the user interface so all the information relevant to a particular user is clearly grouped, and navigation between these tasks is simple and intuitive. After getting more feedback to find out how we could do this you will see that we have made some quite drastic changes.

We are quite excited to show you some first impressions, so we are going to quickly demonstrate the Workspace and Streams perspectives in this blog. This work is currently in development so do not be surprised if more changes are made before the 2009/1 release. We would also welcome any feedback; just comment this article or email to

Active Repository

When launching the new GUI for the first time it will ask you to select a repository. This repository will be remembered the next time you launch the tool. Having a repository centric user interface reduces the complexity of the GUI. For example, the toolbars and menus can apply to this repository, rather than having to select the connection and then the repository every time.

This is particularly apparent for users who only work with 1 repository. User feedback has indicated that about 60% of our users work this way. So if you only have one connection with one repository, the current GUI will feel very ‘clunky’ constantly having to expand the connection, then the repository. If you work on multiple repositories you can change the active repository at any time.

The first thing you will notice is the new ‘Perspectives’ toolbar at the top. Clicking on each of these buttons will launch the corresponding perspective for the active repository. So clicking on the ‘Streams’ button will launch a perspective showing all streams for the active repository.

Having started to use the beta for this, we believe this promotes a more streamlined and focused way of working. Imagine you are in the middle of coding within your workspace perspective but need to quickly view a changeset submitted in another stream. You can switch to the ‘Streams’ perspective and view the changeset. You can then flip back to your workspace perspective and everything is unchanged. The files you were working on are still open, the same tree item is selected, etc.

In the old GUI you would need to scroll down the tree to the ‘Streams’ tree item, expand it to find the new stream, etc. Then when you were done you would need to scroll back up and find your workspace again. The context of what you were working on would be lost and scrolling the tree is a lot more time consuming than clicking a single button.

As the above screenshot illustrates, the ‘Workspaces’ perspective lists all workspaces for the active repository. You can also create a new workspace. Currently we are reusing the old home page here; for the actual release expect a completely new look and feel. You will be able to see which workspaces are out of date, which workspaces you are working on, etc. You will also be able to open a workspace directly using the ‘drop-down’ within the perspectives toolbar.


Workspace Perspective

Selecting a workspace will launch the perspective for that workspace. Once you have selected a workspace, the workspace perspective will automatically be launched the next time you start the tool. So if you are a developer who only works on one workspace you will never need to navigate away from your workspace perspective.

The aim of the workspace perspective is to provide enough functionality so that this is the only perspective a developer will need to use. We think of it as a developer’s ‘home base’ if they are not using the Visual Studio or Eclipse plugins.

The top left window shows the folders within the workspace. Selecting a folder will show the files and folders for the selected folder in the window on the right. This is very much like the workspaces in the current tree control

The bottom left window shows the current changes you are working on. The advantage with this is that you can view/submit your changes without having to move away from the folder you are working on. With the old GUI we found ourselves constantly having to scroll up the tree to ‘My Changes’ whenever we wanted to submit/view our changes and we would need to scroll back down again to the folder we were working on.

You can also view ‘Integrated Changesets’ to see previous changesets submitted in this workspace.  If you are using issues you can quickly look at ‘My Issues’ and ‘Active Issues’ without moving away from the folder you are working on. Finally, the stream tab allows you to browse the stream your workspace is based on. So if you are working on a team stream you are able to see the changes your colleagues submitted.

The toolbar on the right below the perspectives toolbar only applies to this perspective. So the submit, update or check consistency buttons will always be available (when connected) and will always apply to this workspace. This is a big improvement over the old GUI because it means we can have different toolbar buttons for different perspectives.

Note that if you are working on multiple workspaces you automatically create a perspective for each workspace the first time you use it. One of the key advantages with perspectives is that you can then switch between them without losing your environment (which folder is selected, etc.).

Streams Perspective

The Streams Perspective allows you to view all streams within the active repository with all the functionality of the existing GUI. This perspective will be useful for project managers & release managers to create new streams. Project managers will also use this perspective for monitoring the activity of a stream (what changes have been submitted, who is working on what files).

For 2009/1, developers will be able to create a private/feature stream when creating a workspace. So developers will not need to leave their workspace perspective for that purpose.


The main benefits of working in the new GUI are:

  • Repository centric user interface for more streamlined and simpler navigation
  • Group related tasks together to reduce complexity and more intuitive UI
  • Make navigating between different tasks quicker
  • Navigating between different tasks does not lose the context/environment of the previous task

Expect a future blog for the Merging perspective. For 2009/1 we have made this the central place for merging changesets between streams. We have added a whole host of new features such as automatic merging and better tracking of unmerged changes. Combined with workspace rebasing we believe this will make PureCM the ideal tool for agile development.

I look forward to hearing your thoughts on what you have seen...

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!

How to get a quick status report

Have you ever wanted to get a quick overview of what changes have been submitted by a specific developer? Or wanted to know which changesets are present in the current feature stream, but not in its parent? If yes, this blog is for you.

It might be worth to highlight at this point that all the above reports talk about “changes” and “changesets”, and not file or folder differences between streams (of course, you can get the latter information as well, using the PureCM stream comparer).

Creating a report based on changeset is pretty easy in PureCM, just go to the “Reports” node in the Explorer view:


You can find there some example reports, but just click on “New” to create your own. This opens up the report dialogue where you can choose between “Issue reports” and “General reports”. The former are available if you are using PureCM’s issue management, or if you have integrated your issue management tool with PureCM. The latter is based on changesets and gives you exactly the reports we need here.

Follow the wizard, which guides you through a few options, such as the fields you would like to display, which users want to include or which period you are interested in.


Define the report permissions before creating and saving it, just in case there is confidential information involved. Then finish the wizard, and you will get something similar to this:


You can see that these reports are a very simple and fast way to get some insight into your day-to-day development. You are able to export or print your reports for further use, and you can customise their design.

Of course, you might get richer information and a better overview of your project status from issue reports. But this is the topic of another blog to come...

Towards Rebasing


In order to better support Agile development, we're looking to allow easier Workspace Rebasing.  Currently, when you finish working in a particular task stream, you have to create a new workspace when you start work on another.  The idea behind rebasing is that rather than having, for example :-


and 'rebase' to v1.2 and v1.3 as your workload requires.  Of course we'll always remain flexible to allow you to choose your own way of working.

Initial Steps

Before we can make Rebasing a reality we felt that we needed to address some of the Workspace infrastructure.  From inception, PureCM has always had a workspace database that sits alongside your code and holds the revision, checkout and file information about the workspace.  Since this holds the file data (in compressed and delta-ed form) it grows in size proportional to the size of the files in your workspace.  We've always liked this approach since it makes certain operations easy to implement offline (i.e. no server connection)

The first stage of the rebasing work involves minimising the size of the workspace database (since most of the information is thrown away as you rebase).  We're nearly complete now and the results are encouraging.  Some of our internal workspace databases can be reduced in size from roughly 500MB to 10MB.  Obviously the size of the files in the workspace doesn't change but it's quite a healthy saving nonetheless!  Early performance figures indicate roughly a 25% speedup when creating the workspace as well.  These new workspaces can also be used offline although certain functionality is slightly limited (e.g. you can't always view file differences offline).  You can always create a traditional workspace that holds full offline data if this is a concern.

Looking Forward

The next step is to actually implement the Rebasing support.  The initial plan is to provide the UI/Dialog for this from the PureCM GUI as well as the Command Line client.  We can't currently make this work from within Visual Studio - our SCC Provider doesn't have the ability to add custom commands/toolbars so we'll have to look at a true Developer Studio AddIn for added functionality such as this.  The rebasing functionality itself is scheduled to be shipped as part of our 2009/1 release in early 2009. 

Welcome to the PureCM Team blog!

And yet another blog... YES. A big yes!

PureCM has seen its customer base constantly growing over the past two years. And yet, one of the PureCM customers has got quite an overproportional influence on our product development. Ourselves. This is not necessarily a bad thing, don't get me wrong. As we are using our tool ourselves, we've got a high motivation to ship an easy to use and stable product. And we can raise issues that help us making PureCM work better for us, nice features that make our life a little easer, and... uuups.

You've got the point. We want PureCM to work better for you, not just for us. If it does so as a consequence, the better. So this is why we launch "yet another blog". We'll present features that are in the product pipeline to encourage your feedback. We'll show you how PureCM evolves, and what philosophy is driving its development.

I look forward to the next months when members of the development team will start posting. I am sure that you do so, too!