Workspace Management Front and Center

my workspace file is now different, even if I haven't changed it. It would also be nice to know if a file is missing from my workspace or perhaps disappears suddenly from my workspace, because it was moved through some other user interface. The idea is that I can identify attributes and conditions as a normal part of looking through my source tree. I don't have to pull each bit of status information out by querying the CM repository or by looking at a directory listing.

Workspace-Centric Changes

I like to go to my to-do list, look at a problem and select fix-it, or look at a feature and select implement-it. A change package is created, I check out files against that change, edit/compile/test, review the change, and check in the change. I'll frequently have several such changes on the go at once, typically all in the same workspace, but packaged into separate changes which trace to the problems and features being addressed. A change package simplifies my workspace work. I still have to check out each file (sometimes multiple files in one step), but I don't have to check in each separately. I don't have to do delta/difference reports on each file. I don't have to promote each file. I can do these operations on the change, whether its for a single file or a dozen files or more. Change packages reduce the workload of a developer and minimizes mistakes (oops, I forgot to check in one of my files). Task-based check-outs also give some of these benefits.

But some developers want nothing to do with the CM system, or as little as possible. A good way to introduce these developers to the benefits of a CM tool is to use a more workspace-centric approach. They start out by populating their workspace from the CM tool, or perhaps even populating the CM tool from their workspace. Then they continue to do edits and testing in their workspace. Perhaps once a week they check in their workspace. A decent CM tool can look at a workspace, identify files and directories which have changed, moved or been added/deleted, and then create a change package to encapsulate these changes. There's not as much traceability granularity as creating changes tied to each feature or problem. But at least they have a regular history of how their code is changing.

And if all they have to do is drag and drop their workspace root onto the CM tool source tree, they may even be encouraged to do it more than once a week - maybe even after getting each feature implemented or problem fixed! This workspace-centric approach tracks changes by the way the workspace has changed, rather than by the tasks. Is this preferable? No. But it's better than nothing, and hopefully after a few cycles, developers will start taking advantage of their workspace-centric changes and realize that a more regular level of traceability works even better for them. This all assumes that the CM tool makes everything easy and gives payback to the developers.

Workspace-centric changes will be a necessity if CM is to move into the realm of non-technical users: lawyers, accountants, secretarial staff. Perhaps the 4th or 5th generation CM tools will update an accountant's files on a daily basis automatically, without a need to expose him/her to a CM user interface.

Workspace Meta Data

Some CM tools place additional meta data into the workspace. Perhaps to identify source files from intermediate or non-CM controlled files. Perhaps to identify the revision level at which files were checked out. Some tools will