Workspace Management Front and Center

In the 1970's, we had a "tempdir" and a "permdir," with 2 to 20 MB of disk space allocated to each developer. Checked out source code would go into the permanent directory, while intermediate data, which would disappear with each logoff, went into the temporary directory. No tree structure, no 200 character file names, no graphical user interface. It was pretty simple, but effective. Because of disk space limitations, we learned to create workspaces which were incremental to shared workspaces, which in turn were incremental to system-wide workspaces.

In my world, as CM developed over the years, these simple but key capabilities remained important. But there was much more that needed to be addressed.

Typically in a CM environment, you can indicate the view of the world you want to deal with: product, development stream/release, promotion level, specific changes, a baseline, a build, etc. You tell the system the context-based view you want to look at. But there's another view as well - the workspace view. You can indicate a workspace and then ask to compare your view to the workspace. So if my context view is set to a specific build or release, I can ask the system: What's different between my workspace and this release? And if your workspace is older you can even ask to synchronize it with your context view.

In some simpler CM tools, the only context view you can specify is the "latest" view, or perhaps the view on a certain date. And this works fine for projects which can live with this model. In more advanced tools, you can specify your view in a number of different ways: this stream of this product, the build from last weekend, the same one used by this change, the last shipped release. Ideally, these are done simply from the user interface, and not by having to invent a complex specification.

Basic Workspace Parameters

The workspace view is typically rather simple, but not necessarily so. Workspace organizations can be categorized along a number of lines. These include the following:

• Shared Workspace or Parallel Workspaces
• Read-write only on Checkout vs. Always Read-write
• Flat pool shape vs. Tree Structure
• Incremental vs. Full

Shared Workspace vs. Parallel Workspaces Some developers create a separate workspace for each change. Others create a single workspace for all of the changes leading up to a release. Many IDEs support the latter methodology only. The CM tool needs to support both modes of operation. The workspace should be an attribute of a change package, or if you depend on branching to simulate changes, an attribute of the private branch. When code is checked out for a change, it goes to the workspace associated with that change, regardless of your current/default working directory setting. Similarly, the change's workspace is used for check-in operations, change delta/difference reports and merge operations. This allows a great deal of flexibility without always having to switch the user's current working around.

Read-Write Only on Checkout

I like to have write access to all the files in my workspace. This way I can experiment with some changes before I decide that the approach, or even the idea, is a good one. Others like to force a read-only attribute on files which have not been checked out. In this way, they don't accidentally forget to check out a file into a change. The CM tool itself should not have to rely on this attribute to track checked out files. At the same time, it can take advantage of the attributes to take some short cuts. For example, when comparing a workspace to a