Name of the blog

Short description of the blog

File Search Without a Workspace

For as long as I can remember PureCM customers have requested the ability to search server files without creating a workspace. For PureCM customers coming from VSS this was the one VSS feature they missed.

We had a working prototype of this feature 3 years ago but it did not make it into the release because it was too slow and was a performance drain on the server. Finally file search will be available in the 2013/2 release thanks to the redesigned database format introduced in 2011/2, a general improvement in server disk speeds with RAID and better algorithms to perform the search.

How Does It Work


You can right-click any version, release, feature or ad hoc stream and select 'Find In Files'.

From here you can enter the text to search and select whether this is case sensitive. If you select 'Use Regular Expressions' then you can enter a regular expression instead of plain text - but this will only be matched for each individual line.

If necessary you can specify a subfolder of the stream you selected to narrow the search as well as the file extensions to consider.

On pressing Find All a list of files matching the search will appear and you can stop the search at any time with the Stop Search button.

Double clicking a file will open the editor for this file with the first match selected. You can expand a file to reveal the text for the first 3 lines which match. Double-clicking on these lines will open the editor with the match in that line selected.

What is the Performance Like


Within our test environment we found that searching a 10GB stream with 35,000 files took 40 seconds. This is obviously an extreme case - typically you will be searching in a much smaller subfolder. We also found that performing the search had very little impact on the PureCM server responsiveness. Other developers can carry on working without any impact on performance. If multiple searches are performed then the performance for each search will be effected but this will have little effect on other developers updating or submitting.

File search can be performed in the PureCM GUI, the command line or the Visual Studio extension.

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.

AVC 2: PureCM and Agile


In this post I would like to explore more of the Agile Manifesto and how it relates to software development and to delve into some of the reasoning behind why PureCM was designed and built the way it is.

Individual interactions over processes and tools. A cynic might look at this and say this means there is no need for software tools, but that's the point at all. Software tools are helpful and in many cases necessary but your tools should not define your process and you shouldn't be overly dependent on tools for communication. In Agile the right process is the one that works and over time teams might be changing, tweaking, rearranging process to find what works.

In order for an SCM system to be effective in this type of environment in needs to be flexible and adapt to the process instead of imposing process. The right tool is the one that works for you. I want to mention a long time complaint I have had with several SCM systems that impose process either intentionally or through lack of capability. For example AccuRev is a  system where mainline development as an intentional strategy is not supported and Perforce, VSS, CVS only mainline development as a strategy is supported (generally speaking) due to lack of capability.

PureCM has the ability to do basic mainline or complex branch heavy development strategies with any number of combinations in between due to not having a locked workflow and while also having strong capabilities which allow users to adapt PureCM to their process and not the other way around. Change is continuous in the agile flavors and unless it's not practical to think one could go out and buy a whole new set of tools after each tweak to the process, so having tools that can adapt with the right amount of configurability (built in options) is important.

Working software over comprehensive documentation. This entry in the manifesto is a cross-hairs pointed squarely at the waterfall process where every feature and function is documented in great detail before a project even begins. This approach has many pitfalls but in brief what you end up doing is either wasting a ton of time documenting features that never get built (for whatever reason) or adhere so strictly to the original documentation that you lose all ability to adjust to changing market/customer/technology demands over time.

PureCM has adopted a strategy to manage metadata information at the most minimal levels but I will detail this with when I get into Scrum, in short the PureCM task can be reduced to a one-sentence entry and expanded upon over time, detail increases as priority increases so you only spend time documenting features with a high probability of going into development.

Customer collaboration over contract negotiation. Here is part of the manifesto that puts emphasis on including the customer or the key stake holders in the software development process. This can take on different forms in practice from user acceptance testing by the customer, or demo of new features after increments.

PureCM can be a facilitator to this process but it depends on how collaboration is defined and adapted by the team, I will provide several examples once we are Scrumming.

Responding to change over following a plan. Another pitfall of the waterfall process. A lot of software teams might spend months or years working on a project using the original requirements documentation approved by the customer only to find at the end of it all the customer was not happy with the result or conditions in the market had changed enough to make features obsolete before they were even released. With the Scrum adaptation instead of planning out an entire project and a year's worth of effort in advance you plan out short increments called Sprints and this allows priorities to shift in short time to meet the changing demands of the customer.


With PureCM it is possible to actually manage your software development effort by sprints and I will get into greater detail in forthcoming posts so stay tuned!

PureCM Now Offers Subversion Importer

Good news for the many software developers looking to upgrade from Subversion to a more robust change management tool. PureCM now features a Subversion importer that will import an SVN trunk with full history.

Anyone looking to do an evaluation of PureCM will now be able to quickly and easily import real data from an existing SVN repo into PureCM in order to get the best possible test drive of the system in the least amount of time. This will be a huge benefit to people who ask the question, "but how will my projects look in PureCM"? Now you can tell and with minimal effort since the import is a point and click process.

Customers looking to switch off Subversion will also be able keep their old historical data by transferring into PureCM which provides the key advantage of being able to get started with PureCM while retaining your old data. Perhaps a bigger benefit is now you can leverage pre-existing IT infrastructure to properly backup this business critical data by hosting PureCM against SQL Server.

Importing data is an important part of what we do at PureCM. We recognize that many of our customers are switching to PureCM from something else. Importing data through a script or an API is always a possibility but not the quickest and easiest solution and for that reason PureCM has put a lot of effort into providing importers for as many SCM tools as possible, such as Visual SourceSafe, CVS and Perforce; and now Subversion joins the list.

Visit our knowledge base to get a step-by-step guide about how to use the SVN importer.


PureCM can now handle thousands of open features

One change which you will probably not notice after installing 2010/2 is that submitted changesets are automatically merged to features in the background. If you work in a larger team with many developers using features then you will soon see the massive performance improvements.

Prior to 2010/2 when you submit a changeset, this changeset is automatically merged to all features as part of the submit. This means that you are waiting around for this to finish until you can carry on working. Plus the server is locked so other users cannot submit until all the automatic merges are complete. This is not a problem if you have 5-10 open features, but in a team of 100+ developers this can turn into minutes.

With 2010/2 after you submit a changeset it is not automatically merged to any features immediately. If you go to the Merging view you will see that the changeset appears under ‘In Progress Changesets’ for each feature.


The server will then merge these in-progress changesets when it is not busy. So you are not waiting for the merges to complete and the server does not prevent other developers from submitting changesets.

Another neat feature with 2010/2 is that you can move unmerged changesets into the ‘In Progress’ state. So if you have hundreds of changesets to merge into a stream you can simply select all the pending changesets and select ‘Move to In Progress’. You can then carry on working while the server processes the changesets in the background.

Modular Software and Version Control


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

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

To modularise or not to modularise…

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

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

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

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

Shared components – an example

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

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

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


Sharing component releases or all changes immediately?

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

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

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


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


Only share stable component updates

Share component updates immediately

Support one component version only

Link to relevant component release

Link to component version

Support multiple component versions

Link to component release of the relevant version

Link to relevant component version

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

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

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


The advantages of task-driven development


Over the last few years, we’ve seen a large number of development teams moving away from file-based version control tools. This is no surprise, as new tools on the market started to support the concept of changesets and atomic commits.

Why grouping changes makes sense

So instead of checking in every single file, developers were now able to group their changes in changesets. This gives teams a much better project history, as each changeset reflects a task. Also, changesets are applied to the repository database atomically, i.e. completely or not at all, thus protecting database integrity.

Distributed version control systems and, of course, PureCM also allow developers to create, checkpoint or rollback changesets without needing a connection to a central server. But task-driven development doesn’t stop there. You’d want to link your changeset to its original change request or defect in your issue tracking tool.

Easy: add the issue reference as a comment, or link it to your changeset using a 3rd party plugin. But what if you’re working on parallel versions, where changesets get merged across project branches? Do you still know to what versions your change has been applied to? Or how do you track your changes when implementing code reuse across projects?

How to keep track when working with parallel versions?

Typically, only your original changeset will be linked to the original issue, but it quickly becomes a manual and cumbersome process to find out into which releases, say, a particular bug fix has finally made it. This is where PureCM’s end-to-end focus on task-driven development comes in, providing a full picture with on a simple mouse click.

Watch the short 3 minute demo to learn how you can get full transparency between project branches and even when sharing components across multiple projects. Ah yes, here’s the link:

I hope you like it!