RCS DEBATE
[The following is written by Chris Adlard, the software configuration and
quality manager for two of the largest software projects in Australia. ]
Having read the discussion for several days now, I would like to add my
comments.
IJ> Remy Card's championing of RCS to solve the world's problems have
IJ> been clearly shown to be a red herring by David Engel.
I put it to you that no such thing has been done. The following is what
David Engel said.
DE> Remy, you're thinking too much like a software person. Not every
DE> shared project involves a repository of source code that can benefit
DE> from using a version control system (VCS).
DE>
DE> One example is a group of users that need access to shared database.
DE> The DBMS prevents users from trashing each other's entries by locking
DE> individual records as needed. However, users still need write access
DE> to the database.
DE>
DE> Another example is going to be done in Debian 0.92. Ian is setting
DE> things up so any member of group `staff' can install packages in
DE> /usr/local. Surely you're not suggesting that the binaries from
DE> /usr/local/bin be placed under VCS, are you?
David Engel is right, however Remy Card was correcting you on a
completely different issue. The following is the original material to
which he was responding.
IJ> This scheme solves a serious problem, namely that directories for
IJ> group projects are quite simply unmanageable without it.
IJ>
IJ> I have often been in the position of having to do cp -r on large
IJ> directory trees because I couldn't update the appropriate portions.
IJ> Numerous times I have had to 'make clean' before I could 'make',
IJ> because some of the '.o' files were unreadable and some were
IJ> unwriteable.
As is now obvious, you were making a clear and specific reference to
code. David Engel in no way has shown Remy's debunking of the above to be
a "red herring".
Remy Card is quite correct when he says that a revision control system
must be used on any software project. I fully endorse his comments. Ian
Jackson's suggestion of using groups for project work is not a viable
proposition.
Revision control should be used for both development libraries and
product libraries. Development libraries are usually controlled by the
team leader.
After unit testing, product libraries are used. These are formally
controlled by the configuration manager, who is the _only_ person
authorised to change the code.
Revision control systems keep a record of all versions of the code from
the beginning of the project. Fixed sets of code versions for baselines
and releases are 'tagged' for identification. If an earlier version or
release is needed, it is available.
Various methods of locking out multiple developers are used. Some of the
more sophisticated CM packages have built-in locking mechanisms. We are
currently using CVS, a front end to RCS, and have scripts to enable
booking files out to a user, locking out other users, and submitting code
back for approval. Changes must be processed very quickly to free the code
for other developers.
Groups can be used for information that can be shared with no risk of
confusion, such as specifications, informal lists etc. This also applies
to software like databases which have their own built-in locking
methods.
However, this does not apply to _code_. It can never be assumed that a
piece of code will not be changed by more than one person. It is necessary
to be able to define the current state of a project at any time. If you
don't have adequate revision control, then you usually don't have a
project.
Some people may argue against locking out other users, saying that there
are no problems with parallel development or with using the concurrent
versions capabilities of packages like CVS. Parallel development can be
managed under some circumstances, but the risks outweigh the advantages
and it can become a nightmare to control. No package can determine if
merged code is functionally intact - inspection by an engineer is always
necessary.
If anyone wants to challenge me on the use of revision control systems,
I would like to say that I have been a configuration manager/quality
control manager for the last eight years. This has involved large projects
with forty to fifty programmers changing up to four thousand items of
code, often at geographically diverse sites.
Summarising; even a very small project should use revision control, with
CM activites scaled down accordingly to suit.
Reply to: