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?

PureCM currently uses its own database which has developed over the years to become a robust, secure, and flexible solution for most customer needs. There has been demand, however, from customers (existing and potential) to provide the capability to work with more established and well known SQL databases. We plan to have the option for customers to select from many of the most popular variants, but initially we will develop a SQLite solution followed shortly by SQL Server.

SQLite will become the default database type, but the option for PureCM's native database will still be there. So for existing customers there is no need to change to using SQL if they don't want to. A Migration facility will be available to convert existing databases though.

Advantages of using SQL databases include ..

Familiarity - Administrators already have the knowledge for administering sql databases.
Backup - Trusted and established methods for backup of data.
Interface tools - Easier access to data without use of PureCM.

We're implementing SQLite initialy due to its global cross-platform availability, ease of use (Zero-Configuration) and cost (Its free). This makes a good starting point from which expand.

We see SQL Server as a high priority for the large number of Microsoft Visual Studio development teams. As well as being able to integrate the PureCM client with Visual Studio, using Microsoft's SQL Server at the backend makes a lot of sense.

Additional database engines available to UNIX/Linux are also on the radar and will follow after SQL Server. More on this later.

In terms of usability, there should be no change as far as the PureCM user is concerned. The tool will look and feel exactly the same, with no performance disadvantages.

We aim to support SQLite Databases in the 2010-1 release of PureCM.

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

Back to Basics

 

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

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

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

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

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

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

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

Submitting Unfinished Code

 

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

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

Wait. Let’s rephrase that slightly.

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

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

Feature Streams are Easy

 

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

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

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

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

Create a Feature Stream in 10 Seconds

 

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

 

 

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

 

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

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

Automate Merging to a Feature Stream

 

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

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

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

 

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

Feature Streams in Action

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Are Feature Streams Worth It?

 

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

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

Wish List

 

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

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

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

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

We often get in contact with people evaluating an SCM tool for the first time. Most of the time, they work in a small team that has grown. So all of a sudden, the “have you finished working on file A?” or “which folder was the latest version in again?” questions don’t work the way they did before. Things get chaotic and errors start to creep in. Valuable time gets lost. So they start looking around for a tool to help them address these issues.

However, implementing SCM is just as much about how to define and set up the processes, as well as addressing resistance to change. Process might be a big word, but questions like “do I need to support multiple releases? If yes, how?” or “how and how often do I create builds and keep track of them?” have to be addressed even for the most basic implementation. This isn’t a bad thing at all, as going through these issues will already pay dividends.

Some resources to get you started

Of course, you can’t spend all your time on researching either. This is where some input in the form of best practices comes in very handy. CM Crossroads, the configuration management portal, has just put together a great set of articles to cover just that. It’s called “SCM Essentials for Small Teams” and gives an excellent overview about common issues and best practices when implementing SCM.

A somewhat more specific approach covering how to enhance responsiveness to change recently appeared on Dr. Dobb’s:  “Everything Changes: How Dev Managers Can Cope With Ever-Shifting Requirements”. It’s been written by Mike Shepherd, who just happens to be a colleague of mine at PureCM. His article covers key best practices that help you dealing with an ever faster rate of change.

That said, responsiveness to change automatically links to Agile, so you might also be interested to learn more about how to support your agile initiative with a sound SCM foundation. There’s a white paper on our website that sheds some light on the link between SCM and agile: "Agile SCM Adoption - 10 Essential Practices".

I hope you can benefit from these resources – enjoy reading!

 

P.S. Feel free to get back to me directly; I’m happy to discuss.

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.