search order of other directories. So a directory can really be a search path which says - first look in my workspace, then the group's shared directory, then the integration-tested directory for the source files. Although I haven't seen the feature used much, SUN Microsystems introduced a disk or directory layering capability a few years back. I'm a bit surprised that the entire Unix community did not take up this feature, as far as I know anyway. Nor has Microsoft, at least not to my knowledge. Neuma Technology's CM+ tool introduced search paths early in the 1990's and relies on it to enrich it's functionality, especially in the area of builds. ClearCase has an even more flexible search order capability using a virtual file system capability whereby the operating system can see a view of files given by a configuration specification. In general, the search order capability allows a workspace to behave as both an incremental and full workspace at the same time.
Having a search order within the CM tool has its advantages. For example, in CM+, within the guidelines it suggests, Make files can be generated as part of the build procedure such that intermediate archive libraries do not have to be built. Instead, CM+ uses the same Object Library search order the linker uses to search for object files (or to predict their existence based on the compiles that are to be done) and then creates generic (i.e. GNU compatible) Make files with the correct directory/object file path hard coded - which is fine since the Makefile is thrown away until the next build operation. In this way, search order allows the CM tool to expand the workspace concept beyond source file management and into the realm of the IDE, be it a simple Make tool or integration with an existing commercial or open source IDE.
Workspace as a View
A workspace is, in a lot of ways, just a different view of your repository, especially with the more advanced Virtual File System and Search Order capabilities. But it's also a lot different. It's a sandbox and is changing. There may be many such sandbox workspaces. It contains not only repository worthy files, but all sorts of intermediate files, from editor backups to compiled object code to files that just happen to be lying around. As such, there are many different ways to look at it. There's the file system view, which shows basically everything. There's the IDE view which shows that portion of your workspace that's important to your IDE. Then there's the CM view which shows your repository-based files, but hopefully a lot more.
Active Workspace Management
I use the phrase Active Workspace Management to refer to a feature of a CM tool where it tells you about your workspace without you having to ask. Some very simple tools have these capabilities, some very complex ones don't. They're important. What do I want my CM tool to tell me? Well for starters, if I'm looking at a source tree, I want to be able to tell at a glance if a file is checked out or not. Even better, distinguish between my checkouts and those of some other user. I may want to distinguish read-write files from read-only files. And I want to know which files in my workspace are different from the context view I've set.
What else can active workspace management do for you? If someone checks out another file, I want an indicator to appear. If someone checks in a file in my view, I want to see an indicator showing that