Concepts: Workspaces
Topics
Definition 
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.
Explanation
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 developers 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 be appear to be fully integrated.
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.
View Profiles
A view profiles contain information about which subsystems need to be available for development. They specify where to create and promote versions of developed work, and identify stable baselines that need to be available for the project team.
A baseline is formed by identifying exactly one version of all configuration items that comprise the subsystem. Configuration items are the physical artifacts which are placed under version control.
The benefit of view profiles is that developers can create a view and associate it with an existing view profile. In these cases developers do not need to worry about the details of configuring their working environment – the details of how to select the right versions of files to work on and how to promote changes View profiles support a specific usage model and take advantage of several areas of automated support.
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, and
- Dynamic Views.
Snapshot views provides the developer with a stable, unchanging working environment. 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.
Dynamic views do not make local copies of files and 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.
