Simplifying CM: Expanding Possibilities February, 2010 SnapshotCM News

Workspace Browser

The key product-line feature of this release is support for mapping multiple snapshots into a single workspace. In earlier releases, a single snapshot was "mounted" at the root of a workspace. This simple approach worked well for smaller, self-contained projects. However, for larger projects, and especially those sharing code with other projects, this approach led to many workspaces, and managing them itself became a challenge.

In the past, we addressed this by encouraging users to adopt a convention (encouraged by workspace creation defaults) that placed related workspaces in adjacent directories named using the project names or paths. This way, relative paths between different versions of workspaces would be consistent, and therefore could be used for build operations.

In our new release, the new, more powerful workspace model supports combining all related old-style workspaces into a single workspace using mounts. Each mount defines a snapshot and where to put it in the workspace. By replacing each old workspaces with a mount in the new workspace, the directory structure can remain the same as before, except that we now have a global workspace view. We continue to encourage use of a consistent convention of project-named mount points, though SnapshotCM supports mounting on any location, including mounts overlaying a portion of another mount.

Mounts are defined as part of a workspace definition. This is all accessible via the updated workspace manager and workspace wizards, as well as via the command-line.

Here are the features available for new workspace definitions:

• Name of workspace - any unique string
• Location of workspace - location of root of the workspace. Can be any location.
• Working set - encompasses the whole workspace. Contains workspace paths to include or exclude.
• A list of mounts - each mount defines:
  • Which snapshot to mount
  • Where in the workspace to mount it - configurable defaults in the GUI.
  • Which part of the snapshot to mount - defaults to "/".
  • How end-of-line should be handled for text files in this mount.
  • Whether to use concurrent or strict locking policies in the mount.

Most of these remain unchanged from earlier releases. The working set remains similar, though the paths in the working set now refer to workspace paths, not snapshot paths. (In the past, workspace and snapshot paths were identical, so depending on how you thought about it, using workspace paths in the working set now may or may not require a change in thinking.)

However, snapshot mounting requires additional information which can no longer be assumed as in the past. In particular, one must specify where to mount a snapshot. Previously, a workspace's only snapshot was mounted at "/" - the root of the workspace. Now, it can be mounted anywhere. For example, you might mount the /tools/analyzer/Current snapshot on the "/tools/analyzer" directory in your workspace. This may mean that nothing is mounted at "/" or "/tools". Or if something is mounted at the root, then the /tools/analyzer mount overrides any files which may exist in the root mount. Both scenarios are supported.

Finally, one can choose to mount just part of a snapshot. In previous releases, the root directory in the snapshot was mounted. Now, one can mount some other directory from a snapshot.

The powerful mounting capability simplifies sharing code between products by allowing the shared code to be managed separately, yet mounted (shared) into all using project workspaces. Our intent is to even more directly support such sharing in coming releases. Stay tuned.