My software team's needs in a source code system (scs) differ from the usual. This note describes these needs and general aspects of the solution.
A Source Code System
The difference from a standard system hinges around the question of file vs project-level lockouts. The issues of primary importance to us are robustness against "breaking the build", and convenience of use. Naturally must work easily for dialup users too.
Existing sccs-derived systems (like RCS, Source Integrity, PVCS, and every other one I've heard of) don't address these issues. One can use them, with various hacks and forcing of the tool, but the resulting solution isn't very satisfactory, and the work needed to adjust these tools is as much as building a system from scratch.
So we're leaning towards building a custom solution: that way the result will do precisely what we want, and it'll be quicker to construct.
"Breaking the build" is when someone checks a source file into the build system that prevents the product from compiling or running. This happens regularly under sccs-type systems because someone will check in a file, and at the same time someone else will check in a different file. Even if each of the files works ok on its own, the combination may not. The result is a broken build.
A goal of our system is to guarantee that a runnable version of the product can be built at any time. I mean day or night, every single moment. It is unacceptable to ever check out the newest sources and find that the resulting system doesn't work. The guarantee of a solid build makes development proceed much more quickly, and is particularly useful in crunch situations. Maybe we won't have any crunches in our project, but somehow I doubt that...
A system prevents build breaking by allowing one to check in one's new source changes only after checking out existing sources, recompiling the product, and making sure it runs. Typically the system is used in a batch mode: each user works on his/her local machine's copy of the system, merrily changing files. After a few days or a week the user finishes the changes, tests them, and checks in the sources. Since the changes are finished before they're checked in, there's never a problem with partial changes messing up the build.
The other issue is one of convenience. In this approach, one never "locks" a file. This is very convenient, particularly for remote users in which a lock operation involves a dial-up to a potentially unavailable server. It's also convenient when one can't reach the locker for an emergency release.
Here's how conflicts are handled without the use of locks: two people are permitted to modify their own copies (in their own local sandboxes) of the same file at the same time. When the first checks the file in (with the rest of his/her changes), everything proceeds without interruption. When the second does a check-in, the system notifies him/her that there is a conflict and the file in question must be merged by hand. When all conflicts are handled, the checkin is restarted.
In an sccs-type system, the corresponding operation is to ask someone to check in a file even though the changes on it aren't complete, a potentially build-breaking operation.
This is the system we used for Ace. We developed it over a couple of years of dealing with build-breaking problems in a remote-author environment. I mention that just in case anyone thinks we're making up this weird system just to make life difficult
The system results in a series of version files on a central server. These can be used to easily reconstruct any version of the system. Unlike an sccs-type system, there is no concept of "version 3.2 of file X". Instead, there is "file X from version 3.2 of the system". In other words, versioning is over the whole project rather than individual files.
| || |
March 2, 1996: created.
Copyright © 1996,
All Rights Reserved