Name of the blog

Short description of the blog

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.

The PureCM GUI Views: Part 2

Well, this time the title might be slightly misleading. It should rather say something like ‘The PureCM GUI Views: Part 2 – kind of...’, as I’ll not talk about the PureCM GUI client itself, but about the GUI most developers face on a daily, well most probably even on a constant, basis: their IDE.

Whether it’s Visual Studio, Eclipse or any other solution, flicking between tools isn’t just a hassle, it might even lead to (manual) workarounds that potentially affect product quality. With today’s multi-screen infrastructure and powerful integrations, arranging the information you need has become much more flexible and comfortable. We were obviously delighted to see Microsoft adding a proper API to Visual Studio 2005+, allowing us to provide an enhanced plugin, e.g. to suppor custom panes that any developer can arrange the way he wants.

So something that starts off as being better ergonomically might in fact have implications for your productivity and quality of work. Being able to see your current checkouts and group them into one or more changesets clearly helps to structure your work without the need to use ALT+TAB all the time. We’re not alone with this view, as Adrian Bridgwater at ZDNet UK has also picked up on the topic in his app dev blog. And there are also Eclipse enhancements scheduled for PureCM 2010-1.

By the way, the PureCM 2009-2c release that has become available last week includes some enhancements to make the annotated file history work with the Visual Studio enhanced plugin. This might prove a welcome feature, especially when chasing down bugs in your projects. Know who’s last changed a line, when and why.

You can grab the release from our download section; and if you’re not familiar with our these features yet, why not have a look at our enhanced VS plugin online demo?

The PureCM GUI Views: Part 1

Yes, there are many powerful PureCM plugins into Visual Studio, Eclipse or other tools with SCC interface; even more so with the latest 2009-2 release. But if you want to access PureCM’s full feature set or work with the same interface across platforms, the GUI client is the place to be.

This is why I’ll shed some light on the PureCM GUI, starting with this introduction about its default views. However, I plan to do more than one blog on the topic, so if you’d like to read about a specific GUI issue, just let me know.

So what can you see in each of the PureCM views? Which view do I want to use as an administrator, development manager or developer? Let’s start this GUI introduction based on the PureCM Standard edition to cover the three default views available to any PureCM user.

Top level

The PureCM Administration view is the most encompassing view, listing all your server connections, available repositories and workspaces. This is the only view where you can also perform administrative tasks such as creating repositories and managing users, permissions or licenses.

 

Repository level

You’ll have to select the repository you want to work with, say the “Apps” repository (click this button  or use CTRL+R), which will set the context for the following views. The Repository view will then let you browse the repository's project streams and create branches or snapshots on the server side. Development managers can also access the project audit trail, see current checkouts, compare streams/folders and perform merges between streams (there's an online demo on how to organise your repository).

The Workspaces view lists all local workspaces based on any project stream present in the selected repository; in our example the workspaces for Project 1 Development and Project 2 Development. Release managers would see workspaces to pull the latest project version to their build machines, e.g. to perform continuous integration.

You can perform basic workspace operations from this view, but its main purpose it to give you quick access to the one you want to work with. This actually brings us to the final view.

Project level workspace view

This is the view most developers will spend 90% of their time working against a specific code line. To get there, simply select the workspace you want to work with. The PureCM GUI then automatically drills down to the workspace content, showing its files and folders, as well as grouping your changes into changesets.

The workspace is a private sandbox to work on a specific project. Here, you can checkout files, access file history and submit finished changes. You can get specific file revisions or synchronise your workspace to a particular point in time, e.g. to hunt down bugs. But you’ll also see who else is working on a file and what changes they have submitted to the server, so you can update your workspace to get the latest project status. There's also an online demo about the workspace features.

If you're in a hurry, you can also access a specific workspace via the combo box in the top right corner of the PureCM GUI at any times. Simple.

Conclusion

I hope that I’ve been able to show you that each view facilitates work for a specific user group. If you’re and administrator ...well, you know where. If you’re a development manager looking after branching and merging, creating build and release snapshots, or setting up new projects from scratch, the Repository view is yours. And as a developer, select a workspace from the Workspaces list and get a focused view on the specific project you want to work on.

But is the Administration view the same for administrators and developers? Or is there a way to customise available actions, visible repositories and ongoing changes? Yes, there is – and that’s what I’ll cover with my next blog.

 

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

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 2009-1 Preview

Before we talk features

The first blog in the new year, so first of all my best wishes for 2009! Let me use this fresh start to give you a summarised outlook on PureCM 2009-1, our next major release coming with some rather big changes. So now you might expect a huge list with all the main features, but allow me to make a small detour before getting there...

How you would like to look at your data

If you look at your file system, your data is organised in folders and files. Typically, the highest level folder separates your projects. This is also the approach used by most source control tools such as VSS, SVN or Perforce to structure data in their database. You make changes to a copy of your files or folders, and they get sent back to the database and stored as a new revision.

PureCM uses an additional high level object that includes the files and folders of a project: streams. Streams have two major advantages. First, they remember the relationship between each other, making merging (and merge tracking!) much more transparent. Second, they allow for so called “cheap” snapshots, i.e. branching without making file copies. This allows you to setup your configuration for parallel development, increasing productivity.

Depending on the complexity of your shop, you can create as many (or little) streams as you wish to separate projects, teams, development from maintenance etc... All projects –organised in streams – are stored in the PureCM repository database to keep it safe. You can find some examples later in this blog [anchor].

As a development manager, you need to have all information about your projects at hand. You want to know which changes have gone into a project, which bugfixes need to be merged, or where you are including a specific version of a shared library. So the first big change in PureCM 2009-1 is its repository-centric GUI. To structure the large amount of information present in a repository, the new task-specific views filter the information you need to speed up navigation.

NEW: Task-specific GUI views

As a developer, getting your own sandbox to work on a task in isolation is one of the main views you need, so this is what you get with PureCM 2009-1: the project files and folders, as well as your current changes and all submitted changes to the stream your current workspace is based on. You can thus organise your own changes into changesets, and track the submitted changes from your colleagues you need to integrate.

Note the navigation bar just below the menu bar, which gives you quick access to all the task-specific views. Say you are required to switch to an urgent bugfix and would like to get an overview of your workspaces in this repository, just click on “Workspaces” and select or create the appropriate one.

Likewise, go to the “Streams” view to browse the server, branch your project, and create a release or a stable baseline. You can find out more details about the advantages of the task-specific views in this blog.

Once you have finished a task and would like to move your workspace to the next project or baseline, another new feature in 2009-1 helps you to do this easily: Workspace Rebasing. This feature automatically populates your workspace with the content of any stream you select. No need to delete the existing workspace and create a new one anymore.

NEW: Merge paths for parallel development

Talking of streams actually brings us back to the above discussion about the project structure of a PureCM repository. According to the complexity of your projects, your repository might resemble one of the following (stylised) examples:

In example A, the streams remain typically the same and changes get merged (or promoted) from development to QA to Production. Example B shows a mainline development example with release snapshots, while example C extends the former to a multi-product setup with shared libraries.

You can immediately see that you can use stream folders to organise your streams (or codelines). In this way, you can define permissions on the folder level that get inherited by the streams. This would allow you to define release streams as read only or editable, i.e. used as labels or maintenance branches. In other words, any stream will evolve in isolation or stay static after creation, depending on the stream (folder) policy.

With the new 2009-1 release, you will be able to define Merge Paths between any two streams to track and merge changes in real time. Say you know that you want to keep track of differences between “Feature A” and “Mainline”. Create a Merge Path and you will be able to see at any time, which changes are present in one stream but not in the other, just as in the screenshot below.

This information is also visible in the "Streams" view to highlight pending merges in your stream hierarchy. After merging, the changes get moved to the “Merged changesets” node to track them. Note that all that happens directly on the server, without the need to create a workspace for merging (but you could of course choose to do so as an option).

Using merge paths, you will even be able to define automatic merges! This basically means that any change submitted to the base stream gets instantly merged into the destination stream. In case of conflicts, PureCM automatically moves the change to “Pending Changesets” to allow you to resolve the conflict manually. Of course, one can still choose to make a one-off merge directly on the changeset without defining a merge path.

Feature summary

The essence of the PureCM 2009-1 release is its focus on making work with multiple projects easier. It will not just be easier to work with parallel configurations using Merge Paths and Workspace Rebasing, but also to get the relevant information with the new task-specific views. But before I forget: PureCM obviously gives you more than just that, including advantages like:-

  • Eclipse and Visual Studio integration
  • Proxy Server for distributed teams
  • CruiseControl.NET and FinalBuilder integration
  • Shared libraries between projects (called “Components” in PureCM)
  • Integrated issue management
  • .NET/Java APIs

We will shortly publish the PureCM 2009-1 beta2, which I will certainly announce in this blog. I look forward to getting your feedback once you have been able to play around with it!

 

Better Merging - Part 2

Following on from Tim Rutter’s article ‘Better Merging – Part 1’, we have looked at how to improve the merging capability of the tool even further by introducing Merge Paths and a Merging perspective for the 2009-1 release (see Stephen Worthington’s blog on perspectives – ‘PureCM gets a complete makeover’). This is especially useful if you have a staging hierarchy, eg. Development, QA, Release. In such a situation, pushing changes to the next level becomes very transparent. There are many benefits from introducing these merging features, here are the key ones:

Centralized location

A new Merging Perspective provides a central location where users can easily see which changesets have been merged between streams as well being able to carry out required merges. From here users can create new merge paths and see all existing ones. A merge path consists of 4 nodes:

Merged Changesets – Here you can see which changes have been merged from the source stream to the destination stream.

Pending Changesets – Changes that have failed the quick merge process will end up here, allowing you to carry out a full merge, resolving any conflicts (see "Better Merging – Part 1" blog). Changesets can be moved here directly, from ‘Unchanged Changesets’ or all changesets could be moved here for certain types of merge paths. We’re going to introduce an option that would force all changes to become pending for the path. So for example if you have created a child stream and you know you want all the changes that will be submitted to the parent then it makes sense to make all the changesets pending.

Unmerged Changesets – All changes that have been submitted to the source stream, but have not yet been merged to the destination stream are shown here, with functionality to carry out the merge, move to pending, or move to excluded.

Excluded Changesets – When a changeset should not be merged to the destination stream, it can be placed here, helping other users to avoid performing unwanted merges.

Creating the Merge Path..

The display name can be edited to provide a friendly name.

Automatic Merging

Automatic merging optionally takes place when changes are submitted to a stream. So for example, if multiple streams exist that are based on one ‘main’ stream, and it is important that these streams are kept up to date with Main, then a merge path could be created for each of these, with the option to ‘automatically  merge’ switched on (ie Main -> Stream1, Main -> Stream2 etc). This would result in the submitted changes being quick merged to the other streams at the time of the submit. If the quick merge fails, due to conflicts, the changesets would then appear under the Merge Path node as a pending change.

When working with automatic merging, Continuous Integration becomes a very useful practice to control code quality, so look out for a future blog on Continuous Integration...

Further usability improvements

We’re well underway in the development of these new features but have plans for more usability features:

Allowing one off merges to take place from the Merge perspective is an idea we are considering – so rather than having to navigate to a stream, or Workspace, you should be able to use the Merging perspective to do any merge. A ‘My Pending Merges’ node will be useful for developers who have submitted a change to a stream and then need to merge to other streams. This will list only their changesets that need merging. An ‘All Pending Merges’ node will be useful for managers or administrators responsible for overall merging to quickly see what needs merging.

We’re always open to suggestions or ideas so if you have any regarding merge paths, or merging in general, please let us know.