> Have you looked at the various SCID implementations that the
> smalltalkers are doing?
I haven't, and I would appreciate pointers to anything you thing is good. Many years ago I did a technical evaluation of such things, but I'm sure the landscape has changed a lot.
> I'd like to not only have a secure, distributed CM system, I'd also like
> to quit keeping my OO source code in flat files!
You could be saying two things here. You're right in either case, so let me address them both.
If you mean that you'ld like to be able to keep your OO code in some sort of programming environment (e.g. SmallTalk or DeveloperWorks/Java (some people love the latter), then I agree. I tentatively believe that DCMS, as currently designed, would allow you to do that. It manages "entities", which are simply byte strings, and binds "names" (which are also byte strings) to these. In an OO world, the entities could be functions or classes, and the names could be program identifiers rather than file names.
While the current front end for DCMS is designed for working with file systems, it is reasonable to think of it as a filesystem-oriented user agent rather than as the configuration management system per se. An alternative "user agent" could certainly be built for a programming environment.
The missing link, I think, is that DCMS does not attempt to track dependencies in the programmatic sense. The reason is that the semantics of this is both language- and system-dependent. I think it's worth looking at, but one thing at a time. Let's get collections of blobs right first.
If you mean that you don't think the CM storage manager should use one file per object, then ultimately I think I agree with you, but I'm going to do it anyway for the first generation storage manager. At some level, it is none of the user agent's business how the storage manager handles its bits. I can imagine designs that would use a database -- actually, I thought about such a design for a long time. In the end, I concluded that there are many tools for managing, transmitting, and replicating files, and that I want the option to leverage these tools until I better understand what is needed. I overlooked something repeatedly in going through the argument with myself, so perhaps it is worth emphasizing here: these files are write-once and modify-never. This eliminates most of the argument for the database. The only thing that really mutates in DCMS is the namespace on the server, and that's about the one thing that file systems get right.
> To put it in SQL terms, I'd like to just pipe the results of SELECT
> STORAGE_SPEC, METHODS, FUNCTIONS FROM CODE_TABLE WHERE CLASS = MYCLASS
> AND VERSION = CURRENT_VERSION into the appropriate compiler.
Interesting. I begin to get a hint of why per-entity attributes (metadata) seem like a good idea to people. I'm not going to do that in this round, but I think I've considered it enough to understand how to do it later.