Name of the blog

Short description of the blog

Creating Versions Retrospectively

PureCM has always had the ability to create streams from a previous changeset but this has been made much simpler with the 2014-2 release.

Create a Version from the Version History

 

Suppose you are working on Version 2 and have already submitted features A, B and C. You are currently working on feature D.


You now realise that you want to release Version 2 with features A, C and D. You want to release feature B into Version 3.


You can do this by first renaming Version 2 to Version 3. You can then go to the history for Version 3 and select ‘Create Version From’ on the feature A changeset and call it Version 2.


You can now merge feature C from Version 3 into Version 2. So Version 2 now contains features A and C. All developers can now switch their workspace to the new Version 2 and carry on working on Feature D.

You might also consider creating the merge rules ‘Version 1->Version 2’ and ‘Version 2->Version 3’, making submitted changesets pending. This will ensure that submitted changesets are propagated down to the child versions.

You probably also want to delete the merge rule ‘Versions 1->Version3’. Typically you will not want to merge changesets directly from Version 1 to Version 3 – bypassing Version 2.


Create a Release from the Version History

 

You can also create a release from a changeset in the version history. Simply go to the changeset in the version history and select ‘Create Release From’.


This will create a release including all the changesets up to and including the selected changeset. Later changesets will not be included.


Create a Version from a Release

 

Another new feature of the 2014/2 release is the ability to create a version from a release. Select the release you want to create a version from and select ‘Create Version From’.

A classic example where this is useful is where you create a release (Release 1.1) from Version 1 and carry on submitting features into Version 1 which will go into Release 1.2. A bug in Release 1.1 now means you need to create Release 1.1.1 as soon as possible. You do not want to include the new features submitted in Version 1 because they have not been tested. The priority is fixing the bug.

So you will create the Version 1.1 from the Release 1.1.


You will then submit the bug fix into Version 1.1. You can then create Release 1.1.1 from Version 1.1. Finally you must not forget to merge the bug fix back into Version 1. It is probably worth creating the merge rule ‘Version 1.1->Version 1’.

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.

Jenkins and Hudson Plugins coming soon in 2013/2

With the 2013/2 release now less than a month away we wanted to outline some of the major new features.

One of the biggest features of the 2013/2 release is the plugin for Jenkins and Hudson. In case you did not know Jenkins/Hudson is an open source Continuous Integration tool similar to CruiseControl. Hudson was the original application but this was forked in 2010 by unhappy open source developers to create Jenkins.

 

PureCM already has plugins for CruiseControl.NET and FinalBuilder - so why do we want another CI plugin?

 

Firstly Jenkins/Hudson has possibly become the most widely used continuous integration tool. This is down to it's active open source community, ease of installation, ease of use and number of plugins. So if you are looking to choose a new CI tool - CruiseControl, Jenkins and FinalBuilder are 3 of the best available.

Secondly we already have customers who are using Jenkins and Hudson. So if you are already using Jenkins/Hudson then it will be simple to install the PureCM plugin and get going with the PureCM streams.

The final benefit is that Jenkins/Hudson is cross-platform and is more commonly run on a linux server. This is not the case for FinalBuilder or CruiseControl.NET.

 

What does the plugin do?

 

Similar to the CruiseControl plugin the plugin allows Jenkins/Hudson to check if any submits have been performed against a stream and update the workspace to get the latest code. Jenkins/Hudson goes a bit further than CruiseControl in that it lets you browse the workspace files. It also gives you more details about the change - like what files have been added, edited and deleted.

 

When will the plugins be available?

 

Unfortunately the plugin required some changes to the pcm command line so they will not be available until the release of 2013/2 in October 2013. If you want to get a beta version of 2013/2 along with the plugin please email support@purecm.com and we will send you the details.

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.

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.

Which Database Should I Use for the PureCM Server?

With the 2010/1d release, Windows users will now have a choice between using SQLite or SQL Server for the PureCM server. We are currently beta testing the MySQL database for Linux and Mac users so this should become available in the next six months. This blog will help you decide whether to stick with SQLite or switch over to SQL Server. I will also look at the differences between running the server on Windows, Linux or Mac using SQLite.

If you are using the native database (pre 2010/1 release) then we recommend you upgrade to SQLite or SQL Server as soon as possible. Both of these databases have better performance than the native database and are more scalable – so it is a win-win. Details on how to upgrade can be found in the PureCM Knowledge Base.

 

SQL Server or SQLite

 

SQL Server has better management tools and scales better for large teams. So if you have over 30 developers using PureCM we definitely recommend you migrate to SQL Server. If you have over 10 developers then it will depend on the developer usage. If all of the developers are doing frequent submits, merges or workspace creations then SQL Server may give you a performance boost.

If you have less than 30 developers then you need to establish whether using SQL Server will be more expensive. If you already have a SQL Server license then great, otherwise you will need to work out how much this will cost. PureCM can be configured to work with SQL Server Express – but this will not work out of the box. We plan to support SQL Server Express properly in a future release.

If SQL Server is not expensive then you need to decide whether the scalability and management benefits of SQL Server outweigh the performance benefits of using SQLite.

I installed the PureCM Server on a test Windows machine running on the LAN. I got some performance statistics using SQL Server and SQLite when submitted and creating a workspace for about 10,000 files totalling about 1.2 GB of data.

 

As you can see SQLite is about twice as quick when submitting data but only about 20% quicker when creating a workspace.

 

Windows, Linux or Mac Server

 

If you have decided that SQLite is the best fit for you – then you might also want to consider which OS should host the PureCM Server. Here are some performance statistics when using the PureCM GUI on Windows 7 to submit and create a workspaces for servers running the different Operating Systems.

 

So the server OS made no difference for creating a workspace (database reads) but Ubuntu was significantly quicker (over 50%) when submitting the file adds (database writes) when compared to Windows.

 

Windows, Linux or Mac Clients

 

Finally you might be interested to know the performance differences between clients running PureCM. Here are the statistics when running the PureCM SQLite Server on a Windows Server 2005 machine over the LAN. This is using pcm (the PureCM command line client) with the same set of files (10,000 files totalling 1.2 GB of data).

 

As you can see, Mac and Linux are pretty much neck and neck – but Windows is significantly slower. But when you put it in context, taking just over 3 minutes to create a workspace with 10,000 files totalling about 1.2 GB of data is impressive. So regardless of which OS you choose I am confident PureCM’s performance will beat any other version control tool.

SDC, Part 13: Rescheduling (and the consequences for work in progress)

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.
We'll now make a pause in our blog series, look at feedback we get from our readers, and then start filling the gaps. Any comments about topics you'd like to see here are highly welcome!