Name of the blog

Short description of the blog

SDC, Part 5: Developer Workspaces

Up to now, the blogs have focused on a manager's point of view of using PureCM's project features. This blog will focus on a developer's perspective.

Where developers work ..

The workspace is (always) where developers work. This is a local copy of a version, feature or release where the developer can perform day to day operations using features such as Checkout or Submit.

By having a local copy of files and folders the developer can work independently of other developers, and choose when to either integrate others' changes, or when to submit their changes.

A developer can have multiple workspaces at any time and can also switch a workspace to point to a different Version. 

Using Workspaces

As an example of using workspaces I will explain how I currently work ..

I have multiple workspaces, of which two I actively use on a day to day basis. One is based on a feature that I am implementing for the next major release of PureCM (2010-1-r2). The other is for any bug fixes that I am tasked with for the current release (2010-1). As you have seen in the previous blog, versions and features get their own branch in PureCM. This means I currently keep an active workspace for each different PureCM release I'm working on and switch workspaces between features.

The feature has been broken down into several tasks, which on their own involve small amounts of work - roughly no more than a day for each. 

By navigating to the 'My Tasks' tab I can select a task to begin work on, by clicking 'Start'..


Here I can choose the workspace where to carry out the work. In the workspace, I checkout the files relevant for the current task, make the changes, and submit the work. The work is submitted via a changeset. The changeset shows the files involved (edits, adds of new files, and any deleted files). The task is also shown as a tab on the changeset. The task description is automatically added as the changeset description - this can be amended if required.

Usually, before submitting changes, I would make sure the workspace is up to date (with others' changes). This is done with the 'Update to Latest' operation on a workspace node, or the 'Update' button found in the 'Workspaces' page to the right of the relevant workspace (See image below). It is possible to have PureCM automatically update a workspace immediately before a submit. This is one of the options found in the Option dialog found in the 'Tools' menu..

Once submitted, the changes are uploaded to the feature, the task is completed and I can move onto the next task. 

This process is repeated until all tasks in the feature are completed. At this point the feature can be completed. Depending on how the features are set up, this could involve code review before the changes are finally merged into the parent Version.(There will be a blog written soon covering this topic). 

Workspace Switching

Moving on to another feature involves simply selecting a task from the 'My Tasks' list and, when the same workspace is selected, PureCM automatically switches the workspace to point to the new feature that the task belongs to.

As for the other (2010-1) workspace I have, changes are made and submitted directly to the Version. If changes are required on a different version, then the 'Switch Workspace' option in the workspace/Advanced menu allows a different version to be chosen. The workspace is then updated with the relevant files. The 'Workspaces' tab also alows you to 'switch' a workspace..


In Summary


  • Workspaces are local copies of a version, feature or release
  •  Changesets are used to submit changes to the server 
  • 'Update to latest' keeps the workspace up to date 
  • Workspaces can be switched to different versions (automatically or manually)


We briefly touched on the use of tasks in this blog. The next blog will focus specifically on tasks, and working on small work items.