Concept: Workspaces
A workspace is a private area containing the code a developer is coding and testing in relative isolation from other developers and in accordance with the project's adopted standards.
Main Description


Workspaces refer to 'private' areas where developers can implement and test code in accordance with the project's adopted standards in relative isolation from other developers. The Configuration Manager needs to create a workspace environment for each developer on the project.


A workspace provides each developer with a consistent, flexible, inexpensive, and reproducible environment that selects and presents the appropriate version of each file. The workspace needs to be able to provide fine-grained control over both sharing and isolation. This is required because in most projects, developers need to stay isolated from changes made by others; but at the same time, they must be able to unit-test their changes with changes made by certain other developers.

When performing maintenance on older releases, a developer needs to be able to see older versions, binaries, documents, tests, tools, and other objects. In this case the workspace serves as a 'time machine', making everything in the environment, not just the sources, appear as it did in the past.

Each developer's workspace needs to be isolated, for purposes of editing, compiling, testing and debugging. However, the isolation of the workspace should be relative and not absolute:

  • Others should be able to track a developer's work and selectively integrate it into their own.
  • Others should be able to shut out. Until a subsequent integration period, those changes that may prove destabilizing to their own work.

A workspace can be completely private to an individual developer, or shared among a team of developers over a network.

In addition to providing access to source versions, a workspace needs to provide private (isolated) storage for files generated during software development:

  • Working (checked-out) versions of source files,
  • Executables,
  • Other workspace private objects - source code, test subdirectories, and test data files.

A workspace's private storage would be typically located within a developer's home directory on a workstation. A workspace shared by a group of developers might have its private storage area located on a central file server. However, the actual location of the private storage is largely irrelevant. From the developer's point of view the workspace's private storage should appear to be fully integrated.

Diagram shows 2 integration workspaces and a private workspace superimposed on the CM Cube.

The figure above illustrates the notion of private and integration workspaces in the overall context of the CM Cube.

Working Configurations

Working configurations (workspace profiles) refer to particular subsystems that make up a working set for the project. A working set is a list of specific versions of subsystems that must be referenced, or modified, to implement a piece of work. This list may represent the entire system or a subset.


A view provides access to a set of files in the project repository. Moreover, a view provides access to an appropriate set of versions of those files:

  • A new development view may provide access to the most recent versions of the files.
  • Another new development view may provide access to the versions being used by a team working on a new user interface for your product.
  • A maintenance view may provide access to the versions of the files that were used to build a given release of the product.

A workspace, sometimes also called a view, allows developers to make and test changes in private before sharing the modifications with the rest of the team. There are two types of views:

  • Snapshot Views
  • Dynamic Views

A snapshot view provides the developer with a stable, unchanging working environment. It is analogous to a computer directory tree. A snapshot view is populated with copies of the appropriate versions of files from one or more project repositories. Some people use the term "sandbox" for such a directory tree. When a developer wants to see changes made by other team members, she updates her view. This style of working is characterized as a pull model as it relies on actively pulling in the relevant information, rather than it being immediately available through automatic refresh mechanisms.

A dynamic view is a virtual data structure as it appears to contain all the development data. Dynamic views do not make local copies of files, but rely on over the network immediate updating. Dynamic views may be the best choice in the following situations:

  • There is limited client-side disk space
  • You want to take advantage of derived object sharing
  • The development team must work with the latest versions of the code. This feature is particularly useful for integration that requires the latest version of any given software.