Workspace Management Front and Center

context view, perhaps the read-write files are compared first, or are the only ones presented.

Flat Pool Workspaces vs. Tree Structured Workspace

In the old days (1970s), the world was divided in two: Unix and non-Unix. Non-Unix-like systems typically used a flat directory to hold the source code for a product. Unix-like systems typically used a tree-structure to organize its source code. This latter organization was needed initially as an optimization technique for large programs so that the compiler would not have to search large directories for source files (especially header files). But the tree structure also did a good job in organizing the design, and so it persisted even as computers became hundreds and thousands of times faster. A flat pool workspace is simple and convenient - all of the files are in a single directory. It's easy to search and there's only one file by any given name. Today, across all platforms, flat pool workspaces are quite common for smaller programs, or for specific sub-products/subsystems within a larger system. Because of their convenience they should continue to be supported by today's CM tools. One way to help support them is to allow logical design tree-structuring within the tool, while permitting deployment to either tree or pool based workspace structures.

Tree structured workspaces can be further divided into those where the workspace tree structure must represent the entire product tree (or a subset, but with a full path up to the product root), and those where the workspace maps onto a specific sub-tree of the entire product tree. Ideally, I would like to point to a design sub-tree in the CM tool and have the option of deploying it in a workspace representing a pool organization, a product tree organization, or a sub-tree organization. Other operations such as check-in, check-out, delta, merge, etc., should also support the selected option. For example, although I might compile the program in a pool-based workspace, it's quite likely that the deliverables (help files, executables, configuration and data files, etc.) will need to be deployed to a specific sub-tree organization.

Incremental vs. Full Workspaces

Most programs are reasonably small in size (hundreds to a few thousand source files). To compile and link them takes a few seconds to a few minutes. Retrieving them from the CM repository should take significantly less time, though some CM tools are notorious in this area. It is common for developers of such programs to work with full workspaces, retrieving all the source in their workspace needed to build the application. Other programs are quite large, a few thousand to tens of thousands of files.

Although some CM tools can retrieve these files quickly, it is often preferable to use incremental workspaces in large projects. In an incremental workspace, only the source files that are modified are retrieved to the workspace. The remainder are accessed from a shared disk pool for the specific context (e.g. latest integration tested source code or latest submitted source code). Full workspaces require a re-synchronization operation, ideally at the control of the workspace owner, when the test environment provided by the workspace starts to become dated. Incremental workspaces do not need re-synchronization (except where parallel check outs are supported). However, they do require some assistance from either or both of the CM tool and the building tools (compilers, linkers, etc.). The virtual file system of ClearCase permits a straightforward means of using incremental workspaces.

Search Order

In some cases, this assistance can be provided by the Operating System. The VMS Operating System, for example, allows a directory to be defined which is actually a