Feedback to 'Control the Souce'- Murphy's Law, March 2004
return to Murphy's Law
Niall,
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
Niall,
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.
Regards,
Rob Clemens
Chief Software
Architect Aviom, Inc.
Niall,
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.
Ack.
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
Niall,
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
|