Name of the blog

Short description of the blog

Ignoring Files with pcmignore Files

One of the key features of the 2012/2 PureCM release is the introduction of pcmignore files. I want to explain what they are and how they can make life easier for you. If you are familiar with gitignore files then we have some good news - they are identical.


The Problem – The Ignore File Paths Policy


More often than not there are files in a workspace which you do not want to control. These might include user option files or build files. The previous way of handling this in PureCM was to update the 'Ignore File Paths' policy. So the policy might include the pattern '*.obj' to ensure object files are not added to PureCM.

This policy will carry on working the same as before so if this is working well for you there is no need to change anything. But you may not like this way of working for one or more of these reasons:

  • It is difficult to maintain the 'Ignore File Paths' policy, especially if you have different patterns for different streams. If you decide you want to add a new pattern you have to update this policy in each policyset.
  • Users need to access the Administration view to update the policy. It is unreasonable to expect all developer to become familiar with PureCM policies.
  • Users need to be a Policy Administrator to update the policy. It is very common that an Administrator would not want all users to be able to update all policies.
  • You cannot specify complicated rules. For example you could not say "Exclude all files in a 'Debug' directory except the files in '/src/Debug'".

For these reasons many users have stopped using the 'Ignore File Paths' policy preferring to manually remember which files to not add. But this approach is not recommended for the following reasons:

  • New developers might not know which files to exclude.
  • You are less likely to run the Check Consistency Wizard which makes it more likely that you will forget to add a new file.
  • You cannot use the 'Monitor the workspace for file changes' feature which will automatically add files to your workspace when you create them.


Better in Every Way - pcmignore Files


Using pcmignore files will resolves all these issues. A pcmignore file specifies any number of exclude and include patterns. This is similar to the 'Ignore File Paths' patterns but you can specify include patterns the same as exclude.

When you put the pcmignore file in a folder, the include and exclude rules are applied to that folder and any subfolders. So it is easy to specify complex rules like "Exclude all files in a 'Debug' directory except the files in '/src/Debug'". The root pcmignore file will have a rule to exclude all files in a Debug directory. The 'src' directory has a pcmignore file with a rule to include the Debug directory.

The pcmignore files are submitted to PureCM the same as any other file. Other developers start using the new pcmignore rules after they update their workspace. Developers can add new rules or update existing rules easily by checking out the pcmignore file, updating it and submitting the change.


Switching Over


Hopefully you are eager to start using the new pcmignore files. To get going you need to add a file with the name '.pcmignore' at the root of your workspace. This file contains all the exclude and include rules which apply to all folders in the workspace. You can download a good starting point from here.

Note: If you create a new stream from scratch then the default .pcmignore file is added automatically.

There are many example gitignore files which you can download here. pcmignore files and gitignore files are identical, you can even call the file .gitignore.

After adding the root pcmignore file you can go through each entry in the 'Ignore File Paths' and add any useful patterns to the pcmignore file.

The best approach is then to clear your 'Ignore File Paths' policy and run check consistency on a workspace where everything has been built. Look at the files which PureCM wants to add and add them to the pcmignore file. Keep doing this until running check consistency finds no new files.

Flicking Between File Revisions

With the upcoming release of PureCM 2012/1, I expect you will hear a lot about the new web client and performance improvements. But as a developer it is the file history differences window which I am most excited about.

The file history dialog has been redesigned with a tab view at the bottom. The tab view displays contextual information about the selected revision. Initially the Description tab will be selected – showing the changeset description for the selected revision.

Things get interesting when you select the Differences tab. This displays the familiar differences tool showing the changes made in that revision.

So you can quickly switch between revisions of a file to view the changes. This becomes very useful if a file has been changed many times and you are trying to isolate when or why some code was changed.

Note that the File History Dialog will need to be large to show the differences. If the File History Dialog is docked then you can right-click the tab and select ‘Float’ to make more room.

The Annotated History can be used for a similar purpose – but the Annotated History only shows when a line was last changed. Maybe the line was changed in a later revision but this change is not interesting to you? Or maybe you do know exactly which line has been changed? Maybe you know that the file has changed at some point and want to know what the exact changes were.

If you are very perceptive you might have also noticed that there is a new ‘Move to First Difference’ option at the top. If this is selected then when you move to a new revision the Differences tab will automatically select the first difference. This is what you want if you are browsing the changes made to a file. If this is not selected then the Differences tab will stay at the same line when switching revisions. This is what you want if you are looking for changes to a particular line.

You will be glad to hear that the Differences tab works for image files in the same way. It also works for Word and Excel files if they have been setup for xml post-processing.

Working Outside of Visual Studio

Having used the PureCM Visual Studio Client for a couple of years I got a real shock when I had to do some work in Xcode. Creating a read-only workspace and checking out the files manually sounded like way too much overhead. So I created a writable workspace and ran check consistency when I needed to submit. This worked ok, but I really missed the way the PureCM Visual Studio client tracks which files I am editing. So when I got my hands on our 2011/2 beta the first thing I wanted to try was the workspace monitor.

If you flag a workspace as monitored, then PureCM will keep track of when files are added, edited or deleted and automatically check them out. If I leave my PureCM GUI open on the desktop, it is updated immediately as I edit files in Xcode or any other editor. So I can keep track of what files have changed without running the consistency checker every 5 minutes.

When I ran multiple PureCM clients, I was really impressed with how well they synchronized with each other. When I perform a submit in the PureCM GUI, the Explorer and Visual Studio clients will refresh immediately. In particular the Explorer client becomes a lot more useful. I didn’t use this much before because the icons were always needed to be refreshed but I have found I am using it more and more with the new release.

This is just one of the new features in the 2011/2 release. I’ll keep you posted with other new features over the next few weeks. One of the things I am most excited about is the performance – submitting and updating seem to be lightning quick. We are in the process of comparing the times with the other tools on the market. It is looking like 2011/2 will make PureCM the fastest version control tool on the market.

Top 5 Hidden Tips for Developers

Browsing through the PureCM User Guide or looking on our website you will soon come across a list of PureCM’s big features – the features that sell PureCM. However, it is often the smaller day-to-day features which can make you love a tool or hate it. Here is a list of 5 ‘hidden’ features in PureCM which I find useful.

Opening Explorer for a Workspace Folder

I use read-only workspaces for developing because I like to constantly keep track of what files I am changing. This works great most of the time because I am using Visual Studio with the PureCM Enhanced Client, but sometimes I need to work on a file not included in the solution.

Previously I had to find the file in the GUI workspace, check it out, find the file in Explorer and open it. With the Enhanced Client I can now check the file out within Visual Studio using the Workspace Explorer View. This is cool, but I still have the pain of opening Explorer and finding my workspace, because the file cannot be edited in Visual Studio.

Then I came across the ‘Explore’ menu on a folder in the Workspace View. This will open Windows Explorer and take you straight to the selected folder.

Now I have started getting really lazy, to the point where if I need to go to a workspace folder in Explorer I launch the GUI just to use this menu. I find this quicker than having to traverse down in Explorer to find the workspace. I also use the ‘All Tasks | Open command prompt here’ menu to a lesser degree.

Synchronising a Workspace Back to a Changeset

When testing your software you find a bug and have no idea how and when it was introduced. You know it was working when you did your last round of testing 6 weeks ago , but somebody’s broken it. The first thing I do is isolate the changeset which introduced the bug – especially if it is a non-trivial change which someone else has made.

So in my workspace I select ‘All Tasks | Synchronise’ and select a changeset which was submitted 3 weeks ago. I then build it and see if the bug had been introduced. If the bug does not exist then I select a changeset submitted 1 and a half weeks ago. I carry on with this binary chop until I find the changeset which introduced the bug.

Fixing a bug when you can see how it was introduced is a lot easier than fixing a bug without any context. And if the bug still looks difficult to fix – at least you know who to blame and ask for help!

Moving Changes to Another Workspace

In the last place I worked I remember regularly creating a zip of the files I had changed so I could give them to another developer to either take over the work or test that his changes were compatible with mine. Now with PureCM I can simply shelve my changes and the other developer can unshelve them into his workspace. This is easier and less error prone – because my changes will not clobber his changes.

Another use for this which I find just as useful is the ability to unshelve changes into another one of my workspaces. We do a lot of multi-platform development so we have various build machines for the different platforms. We also have various test machines for the different platforms.

So if a customer reports a bug on a specific platform we try and replicate the problem on one of the test machines. Having reproduced the problem we debug it on the test machine. If the fix is trivial we make the changes on the test machine, check the bug is fixed and submit it.

If the fix is non-trivial then I would rather be working on my own machine. I have Visual Studio setup the way I like it with various third-party plugins which I find useful. So I make the changes on my machine and then unshelve them into the test workspace. If the bug is fixed then I can submit the changes. Otherwise I can carry on working on my machine.

Opening Files Within the PureCM GUI

Within the GUI or Visual Studio Workspace View you can right-click a file and select ‘All Tasks | Open with Default Editor’. This will open the file with whatever application is associated with the file in Windows. A useful shortcut for this is to hold down ‘Control’ and double-click.

You can even go one step further and set this to be the default behaviour when you open a file. In the GUI open the ‘Options | File’ page. Open the properties for the relevant file type (e.g. ‘text/*’), navigate to the ‘Editors’ page and move ‘Default Application’ to the top of the list.

‘Line by Line’ History

When debugging you come across a line of code which seems counterintuitive – but has obviously been put there for a reason. Why has it been programmed in this way? As usual there are no comments to provide any insights.

You can right-click the file and select ‘Show Annotated History’. Find the relevant line and select ‘Launch Changeset Dialog’.

Now I can have the changeset description and related files to help me determine why it has been programmed in this way. If it is still not clear then I know who to ask for help.

Wish List

I thought I’d also use this opportunity to outline some of the smaller improvements I am proposing to go into the 2010/1 release. If you agree with any of these suggestions then please add a comment to say so. Experience has shown that an enhancement raised by a customer carries much more weight than an enhancement raised by one of the developers.

Ability to navigate to my workspace within Windows Explorer

I’ve started using the Explorer Client and am using it more than I expected. I thought it would be one of those features which people without Visual Studio or Eclipse would use. But I am finding there are many situations where I want to checkout a file outside of my IDE.

If the Explorer Client had a sub-menu which listed all my workspaces and navigated me to the selected workspace then I would use it all the time.

‘Open Command Prompt Here’ on Linux

Why is the ‘Open Command Prompt Here’ menu only available on Windows? Developing on Linux I use a terminal much more than I do a command prompt on Windows.

Synchronising my workspace within Visual Studio

You can already synchronise your workspace within Visual Studio by using the Workspace View. But it would be even better if there was a toolbar button to do this. When working in Visual Studio I typically only use the Changesets View along with the Solution Explorer. If I can avoid hving to switch to the Workspace View then this is better.

Feedback on what changeset the workspace is synchronised to

After synchronising my workspace back to a changeset there is no way of telling which changeset it is synchronised to. I have a terrible memory so I normally end up writing the changesets down and crossing them off as I go through the binary chop.

I was thinking the ‘Submitted Changesets’ could show changesets which are not synchronised with a warning sign, the same way that changesets which have not been ‘Updated to Latest’ appear.

There is also no indication on the workspace that it is not up-to-date. It makes sense to show the clock icon, the same as if someone had submitted a changeset but you have not ‘Updated to Latest’.

The Old Friend Visual Studio

Everyday while I sit at my desk I have two computer monitors looking back at me, one shows PureCM and the other shows Visual Studio. Most of my time is spent writing code or fixing bugs and for this there are few better tools that Visual Studio. For understanding the code I'm working on and keeping track of all of the changes going into our tool nothing in my opinion beats the PureCM Client. Both tools are vital for daily work but wouldn't it be nice if it could all be done from one tool?

What about SCC integration?

When we talk to customers we find that most developers do not want to work with a separate  client outside of their development environment. However the current way PureCM integrated with Visual Studio has a lot of shortcomings.

PureCM uses the SCC library provided by Microsoft to allow Visual Studio access to source control. The main advantage of this is that it provides a common interface into many different programs such as XML Spy. The huge disadvantage however is that it was designed strictly by Microsoft to fit with source control providers that operate with outdated concepts. The main problem this causes with PureCM is that Visual Studio works on a single file level and cannot cope easily with the concept of workspaces and changesets. This means that most of the core functions you wish to use in your daily work are not performed as well as we would like as we can never perform exactly what Visual Studio is asking us to do.

A second main problem is how ridged the bindings have to be between your solution and PureCM. The pattern of storing stream information in the solution file means every time you make a new stream you have to rebind this information. As the use of streams grows this becomes less and less practical as often you want to make a quick stream to implement a feature away from the main development stream and are left with the overhead of having to rebind every time.

The third main problem with the SCC is that we cannot implement any more functionality inside it. When I first joined the team at PureCM over four years ago we had a good product that fulfilled all of your main source control requirements. Since then the PureCM client has exploded with new features and evolved to make your work flow much simpler. However the Visual Studio integration has remained pretty much the same.

The Future

So here is some good news. From 2009-2 you will have access to a purpose built plug-in specifically designed for PureCM to integrate seamlessly into Visual Studio. This is very exciting for us as we can finally provide a tool that will make PureCM simpler to use. Our overall aim is to provide your workspace perspective from inside Visual Studio. Not everything will make the 2009-2 release but here are a few of the main features.

No more binding solutions to streams. The new plug-in will now work on a workspace level. It knows if your solution is inside a workspace and uses this workspace to access the server.

Simple interface to add your solution to PureCM. If you have a workspace already just copy your files inside and press the 'Add to PureCM' button. If you don't have a stream yet, the same button will give you a simple two page wizard that will create you a stream on the server, a workspace on your client and add your files in a single operation.

Simple way to get your solutions. Get from PureCM now offers the familiar workspace create wizard, but will let you select which solution you wish to use on the server before you create your private workspace. This will then create a workspace with the solution in the root folder.

PureCM toolbar. Now all of your common operations will be accessible from a toolbar inside Visual Studio.

New embedded panel windows. Now you can open up tabs inside visual studio to make it like the PureCM workspace perspective. These include the changesets tab to view and manage the changesets in your workspace. The Explorer tab to allow you to see and manage files from their structure on disk. And also the event log so you can keep track of what is happening.

The best way to understand these new features is to try them yourself. That’s why you will soon find a beta of the new PureCM release ready for download, including the VS integration. Have fun playing around with it and let us know what you think!

Note that Microsoft only supports custom 3rd party tool integrations for VS 2005 or newer. Users of older VS versions can obviously still use the SCC integration to integrate PureCM.

Light Workspace

With the 2009-1 release of PureCM, comes the option of “Light Workspaces”.. The main purpose of Light workspaces was to enable workspace rebasing (see previous blog ‘Towards Rebasing’ October 2008). Currently, each ‘Full’ workspace has a workspace database that contains revision, checkout and file information about the workspace. This is obviously useful information to have, but makes workspaces large and time consuming to recreate. To enable rebasing, we needed to minimise the size of the workspace database. This has been achieved, to the extent that the new workspaces are some 2% of their original size! 

Are Light Workspaces for me?

So now that we have lighter workspaces, what are the benefits and when would you choose to stick with a full workspace? 

The obvious advantage of a light workspace is local disc space – a fraction of the size is required – so recreating a workspace takes a lot less time. Being able to rebase a workspace means you can very quickly switch to a different stream and begin work on it. This is particularly useful when working with many branches, i.e. branch per task patterns.

If you work in an environment that allows a connection to the server most of the time then Light workspaces are ideal as file history can be obtained easily via the repository database on the server. If, however, you work disconnected from the server for a large amount of time, and also require file history then a ‘full’ workspace is still the best option for you. The ability to create local revisions when offline is an advantage of PureCM, as it allows for checkpointing/rollbacks.

Alternatively you could use a light workspace for day to day operation, and also retain a full workspace for retrieving the history of files. This is possible as PureCM allows multiple workspaces, even from the same branch.

How to create a Light Workspace?

When creating a workspace, there is a new option on the creation dialog ‘Store file revisions in the workspace database’ – Uncheck this to create a light workspace. Once the workspace is created, you cannot change this option.

How to rebase a Workspace 

Right click your workspace and choose 'Rebase Workspace'.

The process of rebasing a workspace  uses the same dialog (as the workspace properties) but allows the user to select a different stream. Workspaces can only be rebased if nothing is currently ‘checked out for edit’ in the workspace. Whenever rebasing occurs, the new rebased workspace will automatically become a light workspace.

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...

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.