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. There's another view as well, though: 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 versus always read-write
- Flat pool shape versus tree structure
- Incremental versus full
Shared Workspace versus 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