User Interfaces and Usability for Embedded Systems

Feedback to 'Control the Souce'- Murphy's Law, March 2004

return to Murphy's Law


You covered all of the salient points about basic VCS for embedded projects very well. I did want to point out that there are Software Configuration Management Systems that take VCS to the next level in that they provide additional support for tracking build inputs and reproducing builds. As embedded projects grow, they need more than VCS.

We switched from time-sharing and manual version control to the Domain Software Engineering Environment on Apollo Domain workstations in the late 80's-early 90's. This gave us source control, build control and distributed builds. We could build on ten, 25MHz 68020 Apollo workstations in one hour what took 24 hours on the mini. After HP bought & killed Apollo, we switched to the open systems successor to DSEE, ClearCase, on a mixture of Unix and Windows NT. By this time we were up to many million lines of code for a number of embedded, control and user interface products, created by an international team of developers. Even though we do all the things you suggest for securing builds, these two systems always let us reproduce builds with 100% certainty.

The ClearCase make system doesn't require us to list header file dependencies in make rules. It remembers included files and referenced environment variables from build to build and detects changes. It only rebuilds when necessary. Changing the version configuration specification may expose older versions of files. Make would not rebuild in such a case unless you 'touch' the files. ClearCase accommodates that by using file versions instead of timestamps. it only uses timestamps for changes in checked out files. ClearCase automatically shares builds, as well. The purpose of tracking every build input is reproducibility. This brings a bonus: If another developer has compiled a file with exactly the same configuration, ClearCase will provide that result rather than rebuilding.

ClearCase also versions directories, so you can look back in time and only see those files that were part of the project at that time. New developers can add/remove files from the latest versions of directories. Branch changes on a do not become generally visible until the merge is complete.

ClearCase MultiSite replicates source databases so each site sees the same thing. It prevents multiple checkouts at different sites by forcing each site to use different branches. This makes it very practical to do development at multiple sites, or migrate maintenance once development is complete.

Rational added quite a bit of project management to ClearCase to further beef up the development story. We don't know where IBM will take it next.

Embedded development never had it so good.

Russell Massey
Principal Engineer,
Control Systems Engineering
Honeywell Process Solutions



I just read your article “Control the Source” at embedded.com. Very well-written. You did an excellent job of explaining the advantages and potential pitfalls of VCS systems. I had considered writing a similar article, and even sketched out an outline, but had never had the time to go beyond that.

I had used SourceSafe, PVCS, and (what was the name?.... ) Reliance(?) systems in the past at other companies. A few years ago, I formed a start-up company with a few other guys and needed a way to manage my source. Money was very tight, so it limited my options. However, I knew I needed something. I found a nice little app called QVCS http://www.qumasoft.com . For $25 ($40 for the “pro version), I had a system that would allow gets, check-outs, check-ins, labels, branches, etc. The inventor, Jim Voris, has been a pleasure to work with and has provided excellent support in the rare case that I needed it. Just thought I would mention this system for the thousands of one-man companies out there that realize the importance of version control, but still need to put food on the table!! (No, I don’t get a commission.)

Again, great article.


Rob Clemens
Chief Software
Architect Aviom, Inc.


I would suggest that CVS (not RCS) is probably the most popular source control tool for Unix/Linux Systems and it is also quite popular for windows users.

One of the interesting features of CVS and most high end VCS systems is that it does not depend on locking files. If two people edit a file at the same time, the tool attempts to merge the changes as they are most likely in different areas of the file. If an automatic merge is not possible, the conflict is flagged and must be manually resolved. This concept scares most people who have not used it, but it actually works quite well and I have never (well rarely) had a user that did eventually agree that the CVS concept works quite well for large teams (more than 5 developers). One area where file locking is useful is for binary files.

Cliff Brake
FOM Systems

Niall's response: CVS is a front end to RCS, and you are probably right that it is CVS that most people use. I deliberately just mentioned RCS because I knew that there was a windows version available, and that is the platform many of the readers would be using.


Grant beattie wrote:

Here's an unfortunate twist that makes version control somewhat more painful.

I'm just starting to program with Cypress's new PSoC. In the 6 months that I've been doing so, the IDE/Compiler for the PSoC (called PSoC Designer) has undergone 3 major revisions that require my old projects to be "updated". What this means is that old (saved) code can't be compiled using the new tools, without being "updated" and that new code can't be compiled on the old versions of the compiler at all. And to make matters worse, the PSoC Designer generates some of the code too (which also changes with time as it's bugs are fixed or features added to the built-in API).

It's a freakin nightmare I tell you. We have one project that we have shipped that needs to be archived with the old version of Designer. If we need to change something we need to debate the merits of "updating" the code to the new version (not a big task, but "hello testing...") or uninstalling the new Designer in order to put the old one back in so we can modify only the parts we want to modify. And we've yet to test that to see if it's really even possible -- short of starting the installation on a new "clean" computer.


Grant Beattie

Grant ,

You seem to be suffering from a bad case of combined tools. I have heard of companies taking the hard dik out of a computer and putting it in a safe as an archieve, so that they know they have the combination o f source/tools/operating system when they go back to it. Of course maintaining a separate computer for the old stuff can raise licensing costs too.

Thanks for the feedback. Your message will be posted on the columns feedback site at http://www.panelsoft.com/murphyslaw

Niall Murphy


I thought your article on VCS was very enlightening and an easy read.

I run a small embedded systems design consulting company in St. Louis, Missouri, USA. There's just 2 of us and typically we never work on the same projects so I havent really had a real necessity to adopt a formal (and initially I thought expensive) VCS system. Our informal VCS system involves keeping track of both snapshots of code under development and code releases to clients, using straightforward blanket copying directories to plentiful backup diskspace, and maintaining a single HISTORY.TXT file for the project describing incremental changes and dates. This has worked very well for us in the past. It takes a bit of discipline to remember do this, but effectively coding solo on a project means its not too much of an overhead. Besides, we've been doing it this way for years and the procedure is engrained in us. However, if some of these VCS Systems are available almost free I might try one out just for comparison. Can you, by any chance, recommend a decent affordable (or free) VCS system to run on Windows 2000?

Regarding the part in your article about forgetting to re-enable commented out code while debugging/testing, this may be an obvious suggestion, but here's what we do.......Whenever I make a temporary code change to try 'real quick' I add 'DEBUGPJH ' (PJH is my initials, my coworker uses DEBUGGLM) to each single line instance added or commented out. For multiple line blocks of code commented out or added, I add 'DEBUGPJH start of ' at the top and 'DEBUGPJH end' at the bottom. Then when I'm ready to remove the temporary changes all I have to do is perform a case insensitive partial word global search (easy to do in my IDE at least) for the word 'debug' and all these temporary markers show up ready for correction. I search for 'debug' and not 'DEBUGPJH' to prevent me missing a potential DEBUGGLM or accidental DEBUGpjh. Actually even with a VCS system in place, doing this will still save time as any file difference checking prior to checking back into VCS will cause less differences to be flagged for further inspection.

Thanks, and keep up with the good articles!!!

Peter Heyes,
President, EMSYS Corporation

[PanelSoft Home | Training Courses ]