Workspace Management Front and Center

insert this meta data right into the source files. Then there's meta data to help your IDE figure out where your workspace is (and what your CM context view is) for each of your projects. With a virtual file system solution, this meta data has to be accessible to the VFS. The same holds for a Tortoise-like file browser based CM user interface.

The need for meta data arises from the fact that the workspace can be accessed both from outside the CM tool and from inside. The difficulties arise when file system operations, such as delete and copy, start happening outside of the CM enviornment. How are these to be reconciled with the CM environment. Meta data can help the workspace and CM tools to identify what's going on.

The Ideal Workspace

So what is the ideal workspace. My ideal workspace supports a series of changes, possibly in parallel, over a long period of time, typically the few years needed from the start of release development until support of that release dies down. I'll use a separate workspace for each development stream. If my object files are located in a directory underneath the source code, I can support multiple platforms with the same code base. Ideally, various C/C++ and Java-based IDEs can work with the same code base. I want to be able to make my changes in one place and then test them on multiple platforms if necessary. I suspect you have your own definition of an ideal workspace.

The ideal workspace is an elusive concept. There are too many different types of CM tools, IDEs, application types and work habits. Java is different from Web Content, which is different from C++, etc. Each IDE offers its own take, as does each CM tool. And that's before the users get to define their processes and work habits. So is there any effort to find some standardization?

Short term, not much. This means that CM tools will have to broaden their workspace capabilities to deal with the many variations. But the longer term picture will be brighter. This will be driven by the non-technical CM applications - the broader CM market niches which are yet to emerge. These will address CM of Legal Documents, Spreadsheets, Web Sites, and so forth, but with the twist that the end user will be non-technical. The wider base will result in more vertical standardization. Will this overflow into the technical development world? Not through the user base. But the need for vendors to deal with these markets will force them to standardize basic workspace management terminology and functions.

Apart from that, standardization will emerge only if one CM solution begins to dominate the market - and in my opinion that's not likely.

Quo Vadis?

So where is Workspace Management headed? Active Workspace Management will continue to grow and will likely move into the File System domain. But the real advances will come as the power of the CM tool is able to be tapped more fully directly from the workspace.

Will the CM interface be replaced by the file system (i.e. workspace) interface, or even by an IDE or other application interface? Yes and no. For basic CM, including change management, this is likely to occur and has already in many cases - users will want to do basic CM from their application interface. And for many of the non-technical vertical applications, this may be the only interface users ever see. But for more complex queries, traceability, reporting, a CM-specific interface will always be preferable. It's possible that you'll see the CM interface