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.

Lee has started to talk about merging in his last blog, as he showed how to apply a hotfix to the current development version. I’ll take on his topic to talk about one of PureCM’s most powerful features: automated merging with ‘Merge Rules’.

Where does merging happen?

PureCM is a client/server based solution, so the all project data is stored in a safe repository. As a developer, you work in a so called ‘workspace’, a local copy of any project held in the repository. This solutions has the benefit of supporting both concurrent and offline development.

The following diagram shows you that there are basically two cases when you might merge:

1. When updating your workspace based on a version or feature to get your colleagues’ changes.
2. Directly between branches on the server. Examples for the latter are merging between different versions or development stages of a project, e.g. from development to test.

Updating a workspace is always ‘on demand’ to let the developer decide when to get the changes. Merging on the server can be performed by a user with the necessary permissions, or automatically using merge rules. 

It’s worth noting here that PureCM always merges tasks, i.e. a submitted changeset and not individual file changes. This makes merging extremely transparent, as you’re able to track that you just merged ‘bugfix a’ or ‘feature b’.

Why you want to automate merging with ‘merge rules’

Merge rules are a very powerful feature that allows you two things:

1. Automatically track changes submitted to one branch (source) that are not present in another (destination). For example, the owner of a development version gets notified about new bug fixes made to a maintenance version
2. Automatically merge changes submitted to one branch (source) that are not present in a second (destination).

This means that a development manager can basically work with two levels of automation. Level 1 highlights pending merges and lets him preview and confirm (or exclude) the merges. Level 2 merges changes straight away and only notifies in case of a merge conflict that has to be resolved.

This results in reduced overhead when managing parallel development and avoids human error and regression bugs. Merge rules are created automatically in the following cases:

1. Automatic tracking is enabled from parent to child versions, e.g. from ‘Version 1’ to ‘Version 2’ as seen in the last blog
2. Automatic merging is enabled into features to keep the feature branch automatically up to date and minimise overhead

A development manager can get an overview of all existing merge rules in the ‘Merging’ view. Here, all merge rules between active versions and features are listed. To keep the view tidy and avoid unplanned merging, merge rules are automatically removed as soon as the version or feature is completed.

Customising merge rules

The Merging view is also the place where development managers can change merge rules as needs dictate. They can change existing merge rules from automated tracking to automated merging and vice versa, or create new merge rules from the menu of the ‘Merge Rule’ folder:

The one condition to respect when creating new merge rules is that the source and destination branch must be part of the same branching hierarchy. In other words, they must have a common ancestor, which is typically the case within a project.

Performing one-off merges

Merge rules are the perfect solution if two branches have a longer lived relationship. However, sometimes you just want to merge a single change without the need to create a merge rule. This is very simple in PureCM and can be done by selecting a completed task and select ‘Merge Change To’.

This will bring up a dialogue where you can select the destination. That’s it. 

Merge tracking

Thanks to its stream-based branching, PureCM can track the merge history of any task throughout the full project hierarchy. Simply access the task properties and select the history tab to see to which versions and features it has been applied to.

We’ve actually finalised another nice feature for our next release in July that allows users to list all releases a task is present. If you’ve ever wondered whether a bugfix has gone into this or that release, this new feature will be an invaluable time saver!

Summary

This blog has covered how development managers can take advantage of PureCM Professional’s merging capabilities to automate parallel development.

• Merge rules either track or merge changes automatically
• Existing merge rules can be customised and new merge rules created
• Notifications are automatically made to the owner of the destination version
• Merge rules are automatically removed once a version or feature is completed

Stay with us and learn how you can reschedule tasks and features as part of an agile planning process – even if coding has already started!

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.

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.

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.

Summary

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.

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.

Summary

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.

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.

Any code you write should be submitted within 24 hours. If you have made changes to code on any of your projects which has not been submitted in the last day then you need to read this.

Back to Basics

Let’s recap on why it is importance to check code in frequently:

·        Your changes are safe – so they won’t be lost if your laptop breaks.

·        Other people can take over your work – if you have to go on emergency leave.

·        You can rollback changesets – if you want to revert your recent changes.

·        You can identify bugs quicker – isolating a bug to a small change makes it easier to fix.

·        Each changeset describes the code – it is much easier for someone to work out what a piece of code is designed to do if it was submitted in a small self-contained changeset.

I hope we all agree on most (if not all) of these points, otherwise you question why you are using version control at all.

Submitting Unfinished Code

One of the golden rules of version control is that you don’t submit unfinished code. You can work in your private workspace to develop and test your code in isolation. When you are finished you submit your changes to the Development Stream.

So if it takes a week to develop and test my changes, I can only submit my changes when it is finished.

Wait. Let’s rephrase that slightly.

So if it takes a week to develop and test my changes, I can only submit my changes to the development stream when it is finished.

You can therefore create a feature stream for your changes. In the feature stream you can submit as often as you want. When you have finished your changes you can merge them all back into the development stream.

Feature Streams are Easy

I bet there are some people who stopped reading this as soon as I mentioned the term ‘feature stream’ – development is complicated enough without having feature streams. But let’s break this down and look at why feature streams are perceived as complicated:

·        I’m only going to be working on this change for a week. I can’t be bothered setting up a new stream and everything else.

·        I don’t want the complexity of merging changes to and from the feature stream.

Now let’s look at these 2 points in turn.

Create a Feature Stream in 10 Seconds

In the PureCM GUI go to the Repository View. In the folder containing the development stream(s) for this project create a new stream folder and call it ‘Stephen’s Features’.

Now right-click the development stream and select ‘Create Stream From’. Call the stream ‘Feature A’ and put it in the new stream folder.

That is it! For the next feature you won’t even need to do the first step.

You can now right-click a workspace for the development stream and select ‘All Tasks | Rebase Workspace’. This will change your workspace to use your new feature stream. Since the files in the feature stream are currently identical to the files in the development stream the rebase will take no time at all.

Automate Merging to a Feature Stream

I lied. It might take 20 seconds to create your first feature stream.

There is another step you should perform after creating the feature stream folder. Right-click the ‘Stephen’s Features’ folder, select Properties and go to the ‘Merge Paths’ page. Uncheck the ‘Inherit Merge Path properties from parent’ checkbox.

Note that this functionality is only available with the Professional Edition. You can use feature streams in the Standard Edition but merging into the feature stream will have to be a manual process. If you are using the Professional Edition then you need to enable the ‘Professional Policies | General | Merge Path Administration’ and ‘Professional Policies | General | Enable Merge Paths’ policies if you have not already done so.

OK. I know this dialog can look a bit scary. But just go with me and select the checkboxes as shown above. What this mean is that whenever a changeset is submitted in the development stream it will be applied to the feature stream.

Feature Streams in Action

Now the feature streams are all setup, let’s see them in action. In the Repository View delete the old ‘Feature A’ stream (because it was created before we updated the stream folder permissions). Create a ‘Feature B’ stream and rebase your workspace to it.

Now pretend someone else is working on the development stream by creating a workspace for the development stream and submitting a simple changeset. If you now go back to the Feature B workspace you will see that the workspace is out of date and the Submitted Changesets shows the new changeset as outstanding.

Look familiar? The workspace is exactly the same as if you had been working in the development stream. You just need to update your workspace to get the new changes. So as you can see, in the general case where the files you are working on have not been changed by someone else, working in a feature stream is no different to working in the development stream.

Let’s see what happens if another developer changes a file which you have already changed in the feature stream...

Submit a change in the workspace for the feature stream. Remember that the big advantage with feature streams is that the change is not pushed to the server until you say. So this submit could just be a checkpoint of unfinished work.

Now go to the development workspace and submit a change to the same file. You will see that this submit succeeds. This is correct because changes in the feature stream should have no impact on developers working in the development stream.

If you look at the feature stream in the Repository View you will see that it has Pending Merges.

This is telling you that a change was submitted in the development stream which conflicts with changes in the feature stream. Right-click the pending merge changeset and select ‘Merge Change’. This will launch the Resolve Tool – exactly the same as if you had done an update to latest in the development workspace which caused conflicts.

In other words, the only difference between working in the feature stream and working in the development stream is that you need to merge any changesets with conflicts.

You do not even have to go to the Repository View to view your Pending Merges. Within a workspace you can use the menu ‘Workspace | Show Server Files Tab’ to launch a window showing the Pending Merges.

The final piece of the jigsaw is how the submitted changes in the feature stream are pushed to the development stream. Let’s demonstrate this by submitting another changeset in the feature stream workspace. So we now have 2 changes submitted in the feature stream and we want to merge them back to the development stream as a single changeset.

Go back to the Repository View, right-click the development stream and select ‘Merge Changes’. Select the feature stream as the source stream. You will see that only the changesets submitted in the feature stream are listed. Check all of the changesets and press Finish. Don’t choose for PureCM to automatically merge the changesets, because this will merge each changeset individually.

PureCM will then launch the Resolve Tool showing you all of the changes you have made and allowing you to change the description. When you press ‘Save’ the changeset is merged back into the development stream.

So as you can see. The process of pushing the feature stream changes back to the development stream is similar to the process of submitting a changeset. The only difference is that you have the slight overhead of using the Merge Wizard.

Remember that there cannot be conflicts when merging your changes back into the development stream, because you have already merged all the development stream changes into your feature stream. The merge will always be trivial.

Are Feature Streams Worth It?

As a developer, if you value the ability to checkpoint your code often so you can revert back to it, then yes I think the small overhead with feature streams will be well worth while.

If not then you might decide that you are happy working without them and only submitting every week or so. But if the day comes when you end up loosing a week’s work because your laptop breaks or your release is late because a developers had to take emergency leave then you might wish that you had been using feature streams.

Wish List

PureCM handles features streams well, but there is plenty of room for improvement. Thankfully most (if not all) of these new features will make it into the 2010/1 release (April 2010).

·        Simplify pushing the changes back into the development stream. There should be a toolbar button on the workspace which merges all the changes back into the development stream.

·        Automatically resolve pending merges when updating the feature stream workspace. This functionality would then be identical to when working on the development stream.

·        Distinguish between feature streams and other streams. For example, when displaying the submitted changesets the release streams are very relevant while the feature streams are not.