Name of the blog

Short description of the blog

SDC, Part 8: Code reviews using features

We've seen how developers can work with both tasks (for small work items) and features (for larger work items). This blog will look at how code reviews can be achieved using features.

Why Reviews?

As a developer completes all the tasks required for a feature, without code review, the option to 'Complete' on the feature is used. Submitting the resulting changeset would merge the feature into the parent Version immediately, close the feature, and stop any code changes from being merged into the feature (from the parent Version). This means that the developer's code is added to the main (parent) Version without any kind of formal inspection or review by someone other than the developer.

This is perfectly acceptable and a common way of working, but in many cases it is a requirement for code to be reviewed before being submitted into a main version. By using reviews, a feature can be given to a manager (or group of), to perform a review of the code changes. The result of the review is either to accept the changes, and commit them to the Version, or reject them.

When rejecting a review it is usual for the feature to be handed back to the developer to complete any outstanding requests.

How to enable Reviews

Because of the isolation of a feature it is very simple to use it as a platform to review the code. Reviews 'come for free' simply by assigning the feature to a user or group of users other than the developer.

So for example.. 

A feature is assigned to a 'Lead Developer' (who is responsible for the review) - this makes them the owner of the feature, and the tasks of that feature are assigned to a 'Developer'. The developer completes the tasks as previously described in earlier blogs. As the developer completes the last task of the feature, this feature appears in the Lead Developer's list of 'Pending Features' (under 'My Tasks' and also 'Workspaces' tabs)..

Here the Lead Developer clicks on the 'Complete' button and is presented with the changeset dialog showing the files to be reviewed. Each file can be viewed and changes scrutinised. The 'Submit' button is used if the changeset is acceptable. This results in the changeset being merged into the parent Version. 

If it is decided that the changeset should not be submitted (ie. rejected) then the dialog can be closed and the Lead Developer can create new tasks for the feature and assign them to the developer.

These tasks would then appear under the Developer's 'My Tasks' list as before, and the feature would no longer appear in the Lead Developer's task list, until the new tasks are completed.

In Summary


  • The isolation of a feature allows for an easy way to perform code reviews.
  • By assigning the Feature to the manager and the tasks to the developer, the review process is automated.
  • The reviewer can accept a feature by submitting the changeset, or introduce new tasks to the feature for the developer to perform.

In the next blog we will focus on the project manager again and look at project reporting.

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 6: Working on a small work item: tasks

In this part of the SDC series we are focusing on a developers day to day life. Last time Lee looked at developer workspaces, now we are going to look at how tasks interact with and manage those workspaces.

My Tasks

We already introduced the concept of a task in my last blog looking from a managers point of view. To a developer a task represents  a small chunk of work that has been assigned to them to complete. These can be easily viewed from the 'My Tasks' area.

As you can see the tasks in this view are broken down into three sections; 'Working', 'Assigned' and 'Group'. These divide the tasks between those that have been linked to a workspace and those which have not. Each section is sorted by priority to help you complete the most important tasks first.

To link a task to a workspace select start button. This will launch a dialog to let you select your workspace. By default it will highlight a workspace connected to the same version as the task. You can always chose to switch an old workspace by selecting it. If no workspaces exist it will launch the new workspace dialog and automatically select the correct version.

Group Assigned Tasks

These are tasks that have been assigned to multiple users using a group. This does not mean that they all work on the same task together, instead it provides a good way for managers to put tasks into a pool for a team to complete (This can be great for end of release bug fixes). As soon as a developer starts work on a task he removes it from the pool and assigns it to himself.

What does Complete do?

For both assigned and group tasks you get the option to complete it. This is designed for when the task is completed without any changes to the server. These cases can include testing tasks or simply tasks that have been completed already.

Working Offline

If you ever need to work while being disconnected from the PureCM server you will be happy to know that tasks assigned to you are stored locally for you to continue working.

Inside your workspace

Each task linked to a workspace acts as a changeset. You can work on multiple tasks at once as different changesets by simply starting work on multiple tasks.

Sometimes you may have no choice but to implement two tasks as one changeset. In this case PureCM allows you to submit the changeset with both tasks assigned to it. From the submit dialog you need to switch to the 'Tasks' tab and select all of the tasks you intend to submit.


When you know which workspace you are working in and want to select the next task without changing your view, select the 'Current Tasks' node and choose the 'Work on Task' item. This provides you with a way to select the task you want to work on or even create a new task inside the correct version.


In Summary

  • You can complete a task without submitting a change from the My Tasks view.
  • Tasks can be assigned to a group to allow any developer from the team to work on it.
  • Tasks assigned to you are stored for offline work.
  • You can link multiple tasks to a changeset by selecting them in the submit dialog.
  • You can create new tasks from inside your workspace using the work on task dialog.

The next blog will look at larger work items that are too big to handle with a single task.

SDC, Part 5: Developer Workspaces

Up to now, the blogs have focused on a manager's point of view of using PureCM's project features. This blog will focus on a developer's perspective.

Where developers work ..

The workspace is (always) where developers work. This is a local copy of a version, feature or release where the developer can perform day to day operations using features such as Checkout or Submit.

By having a local copy of files and folders the developer can work independently of other developers, and choose when to either integrate others' changes, or when to submit their changes.

A developer can have multiple workspaces at any time and can also switch a workspace to point to a different Version. 

Using Workspaces

As an example of using workspaces I will explain how I currently work ..

I have multiple workspaces, of which two I actively use on a day to day basis. One is based on a feature that I am implementing for the next major release of PureCM (2010-1-r2). The other is for any bug fixes that I am tasked with for the current release (2010-1). As you have seen in the previous blog, versions and features get their own branch in PureCM. This means I currently keep an active workspace for each different PureCM release I'm working on and switch workspaces between features.

The feature has been broken down into several tasks, which on their own involve small amounts of work - roughly no more than a day for each. 

By navigating to the 'My Tasks' tab I can select a task to begin work on, by clicking 'Start'..


Here I can choose the workspace where to carry out the work. In the workspace, I checkout the files relevant for the current task, make the changes, and submit the work. The work is submitted via a changeset. The changeset shows the files involved (edits, adds of new files, and any deleted files). The task is also shown as a tab on the changeset. The task description is automatically added as the changeset description - this can be amended if required.

Usually, before submitting changes, I would make sure the workspace is up to date (with others' changes). This is done with the 'Update to Latest' operation on a workspace node, or the 'Update' button found in the 'Workspaces' page to the right of the relevant workspace (See image below). It is possible to have PureCM automatically update a workspace immediately before a submit. This is one of the options found in the Option dialog found in the 'Tools' menu..

Once submitted, the changes are uploaded to the feature, the task is completed and I can move onto the next task. 

This process is repeated until all tasks in the feature are completed. At this point the feature can be completed. Depending on how the features are set up, this could involve code review before the changes are finally merged into the parent Version.(There will be a blog written soon covering this topic). 

Workspace Switching

Moving on to another feature involves simply selecting a task from the 'My Tasks' list and, when the same workspace is selected, PureCM automatically switches the workspace to point to the new feature that the task belongs to.

As for the other (2010-1) workspace I have, changes are made and submitted directly to the Version. If changes are required on a different version, then the 'Switch Workspace' option in the workspace/Advanced menu allows a different version to be chosen. The workspace is then updated with the relevant files. The 'Workspaces' tab also alows you to 'switch' a workspace..


In Summary


  • Workspaces are local copies of a version, feature or release
  •  Changesets are used to submit changes to the server 
  • 'Update to latest' keeps the workspace up to date 
  • Workspaces can be switched to different versions (automatically or manually)


We briefly touched on the use of tasks in this blog. The next blog will focus specifically on tasks, and working on small work items.



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.


SDC, Part 3: Defining a work item hierarchy


SDC part 2 looked at managing your project structure using versions and releases. This blog is an introduction to creating, organising and scheduling work between your releases.


Specify your Work

We need a way of recording work that needs to be done. Using PureCM projects this is done using both Tasks and Features.


A task is the basic building block of project workflow. Ideally it should be a small self contained item that will be submitted as one changeset. Large pieces of work should be broken down into the smallest chunks possible. Code changes you make will be recorded against a task, so you can track its full history from creation to completion.


A feature is a piece of work that is too big for a single submit. We have all been in situations where we are sitting with a couple of days changes in our workspaces that we don't want to submit because they are incomplete and may break others' builds. This is obviously bad practice as you often have no backups or checkpoints and it becomes increasingly hard to manage. A feature gives you a branch where you can submit your changes and then choose when they are merged into the version. This has the added advantage that the version remains release ready at all times.

A good way of working with features is to break down the work further into tasks inside the feature. This has the advantage of helping developers keep track of the work to be done and helps managers keep track of the progress of the feature. It also is an easy way to assign different parts of the feature to different developers.


Scheduling your Work

Now you have some tasks and features you need to decide in which version they will be completed. Tasks and features can be created directly into a version. This can be really useful for bugs when you know which version they need to be fixed in, but future development ideas can be harder to place into a version.

Project Backlog

The project backlog is a place where you can create and store tasks and features that you have not yet scheduled to a version. It can be good practice to have developers raise tasks in the backlog for a manager to schedule into the correct version. Scheduling tasks and features is particularly easy as it can be done by drag & drop.

Organising your Work in Folders

Keeping your tasks organised is an important job, and it can be very useful to group together tasks and features which share a close relationship. This is done through the use of Folders. Folders can be made in both versions and the project backlog.


Getting the work done

Now we have our version full of the tasks we want to complete, so we can assign them to the relevant developers. By giving each task a priority we can also define a work flow for the developer as their highest priority tasks will appear at the top of their to-do list. Remember you can always (re-)assign or change the priority of multiple items at once from the Projects view.



In this blog you have learnt:

  • The difference between tasks and features and when to use them.
  • How to schedule your tasks against the correct version.
  • What the project backlog is and how to get the most out of it.
  • How to organise your tasks using folders.
  • How to assign tasks to developers to get the work completed.

The next blog 'SDC Part 4: Branching Patterns' will give you a look at what creating versions/features/releases does behind the scenes and how you can best set up your project to make use of this.

SDC, Part 2: Release and iteration planning

This blog is an introduction to creating projects, versions and releases using PureCM 2010.

Creating a Project


The first thing you need to do is create a PureCM project. A project is a self-contained set of files. You can share files between projects using components, but this is too big a topic to discuss here.

Launch the PureCM GUI and go to the Projects View. Right-click the ‘Projects’ tree item and select ‘New Project’. Here you can specify a name and description for your project

Creating Versions


A project will contain one or more versions. How many versions you create and what you call them will depend on how you develop your project.

The first question you need to ask is: Do I need to develop different versions of the project at the same time? If the answer is no then you only need a single version – probably called something like ‘Development’ or ‘Main’. If the answer is yes then you need to create a PureCM version for each version you will be working on.

For example, suppose the project is a website which is constantly being updated and the latest files are uploaded to the web server at various points. The project needs to only have one version.

Or suppose the project is an application which is released as incremental versions, but each version contains the latest code. The project needs to only have one version. You could create a PureCM version for each version of the application – but it is more work for you.



Now suppose the project is an application which is released as incremental versions, but each version does not contain the latest code. So for example you release ‘Release 1.1’ and start developing ‘Version 2’. You then find a bug in ‘Version 1’ so you want to release ‘Release 1.2’. But you do not want ‘Release 1.2’ to contain the ‘Version 2’ features (Features 2 & 3). The project needs to have a version for ‘Version 1’ and a version for ‘Version 2’.




To create the first version right-click the project and select ‘New Version’. Here you specify a name for the version. The initial version will always be created from scratch. To create a version from another version right-click the first version and select ‘Create Version From’. You will notice that now the new version is based on the version you selected.

It is very important that any new versions are created from the correct version, e.g. ‘Version 2’ is created from ‘Version 1’. This is so that ‘Version 2’ will initially contain the same files as ‘Version 1’.

Staging or Promotion Models


Another reason to create versions is to support staging. The most common example of this is where you have a ‘Development Environment’ where your developers submit code and an ‘Integration Environment’ where your testers test the code. What you want to avoid is having a code freeze – stopping your developers from submitting changes until the testers have tested the code.

To achieve this simply create the ‘Development’ version as described above. From this you can create the ‘Integration’ version. All the developers will work on the ‘Development’ version and at various points a manager can merge the changes into the ‘Integration’ version.




To support staging and parallel development you need to create the staging version from each development version. So you will initially create the ‘Version 1 Development’ version and from this you will create the ‘Version 1 Integration’ version. When you are ready to start developing Version 2 you will create the ‘Version 2 Development’ version from the ‘Version 1 Development’ version. You will then create the ‘Version 2 Integration’ version from the ‘Version 2 Development’ version.




Of course you are not restricted to one staging environment. For example, you might create the ‘Production’ version based on the ‘Integration’ version.

Iterations or Sprints


A common question is how to handle iterations or sprints and whether you should create versions for them. The same rules apply here as with parallel development. If you are working on 2 or more iterations/sprints in parallel then they should be separate versions. If the development is linear then you only need one version.

Creating a Release


A release is a snapshot of the version at the time the release was created. By default, the files within the release will not change. So a release is used by the build managers to build the release and by the developers to test for a bug within the release code.

To create a release, right-click the version you want to create a release from and select ‘New Release’.

To view the releases of a version, right-click the version and select ‘Show Submitted Tasks and Releases’. This will give you a list of the changes submitted against this version and where the releases were created.






In this blog you have learnt:

  • How to create a project.
  • If you work in parallel development then you need to create a PureCM version for each new version of the project.
  • If you work with staging environments then you need to create a PureCM version for each stage.
  • When creating a version it is very important to create it from the correct version.
  • How to create a release and view all the releases for a version.

The next blog ‘SDC Part 3: Defining a Work Item’ will describe how to create tasks and features within a version and assign them to a developer.

New Blog Series: Solving Development Challenges (SDC)

The last PureCM 2010-1 release has added some very powerful features to PureCM. But how do they relate to day-to-day development? And how to get started? These questions are at the core of our new ‘Solving Development Challenges’ (SDC) blog series that kicks off with this one. So watch out for our SDC blogs to learn about how you can facilitate your software development with PureCM! 

One challenge, one blog

The next blog in a few days time will look at project planning from a project manager’s perspective. Then we’ll take the development manager’s view on configuration management before looking over the shoulders of a developer working on his tasks. Each blog will cover a specific issue and conclude with 3 key lessons. If you are missing a challenge you’d like to know more about let me know by commenting any SDC blog or starting a discussion in our forum

Covered topics

We’ll initially focus on challenges within the scope of PureCM Professional, which is quite a bit since the release of 2010-1. The following diagrams give you a quick overview about what’s supported by each PureCM edition. Note that fully included functionality is highlighted in red, while PureCM can also integrate with ‘blue’ tools:


                PureCM Professional                                             PureCM Standard


To complete this first SDC blog, let me clarify some glossary that will be used throughout the series. This is particularly important when covering the development lifecycle as a whole, with project and development managers working from the same UI in PureCM Professional. These issues will of course be revisited in more detail throughout the blog series.


Understanding each other


Project Manager

Dev Manager

Create or define a release

I define releases to plan (and track) the scope of the next project version that gets shipped to our customers.

Thus, I need to be able to schedule the features and fixes that it will contain, typically based on team members' high-level estimates. 


è PureCM calls this action ‘creating a version

When I create a release, I take a snapshot of the current configuration of the project files and folders that was built and shipped.

This snapshot (or label/tag) is static, so I can retrieve and rebuild a release at any time.


è PureCM calls this action ‘creating a release

Using high-level work items such as features or stories

I want to be able to define high-level features to describe new functionality.

Development then defines the sub-tasks that are required to complete that feature.



è PureCM uses ‘features’ or ‘folders’ to represent high-level work items. Which one to choose depends on the needs of the development manager.

I want to be able to isolate developer(s) working on a feature on their own branch. That gives me the choice when to integrate it back, i.e. with which iteration or release to ship.

But that should be possible with minimal overhead for developers and myself.


è PureCM uses a branch to represent each 'feature' by default. To group multiple tasks without creating a branch, use ‘folders’. Of course, folders can be made features at any time.

Working on multiple releases in parallel

I just need to be able to plan and track multiple project versions at the same time.

I might want to distinguish between maintenance and development, but typically I'm more interested in development.


è PureCM allows creating multiple versions for each project, so work items can be scheduled accordingly.

è  Version naming is fully customisable.

To be able to support parallel development, I need to work with branches.

Typically, I’ve got at least two branches: one for maintenance on a live release, and one for development on the next release.


è PureCM uses a branch to represent each version by default. Of course, this is fully customisable.

è Work items scheduled against a specific version automatically populate the developer workspace with the correct project configuration to facilitate communication and avoid errors.


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.



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