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