Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!think!ames!amdahl!pyramid!prls!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.software-eng
Subject: Re: Paradigms for source control
Message-ID: <2846@mmintl.UUCP>
Date: 13 May 88 21:06:38 GMT
References: <5291@cup.portal.com>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Ashton-Tate Corporation, East Hartford Development Center
Lines: 81

In article <5291@cup.portal.com> jxh@cup.portal.com writes:
>I have been sort of working on Revise, which is a descendent of UPDATE/MODIFY
>from the Cybers, in that it has some of the same basic assumptions, namely
>that there are Decks containing Lines (they got rid of the word Card at
>this point), and that lines may be Active or Inactive, and that they may b
>inserted, and deactivated, but not actually deleted, by a modset.  A
>modset can also reactivate "deleted" lines.
>
>There are those in Unix land who use a program called SCCS, and [others].
>They operate by controlling the "checking out" and subsequent "checking
>in" of modules.  One checks out a module, edits it, and checks it in,
>identifying a "version" as the label for this instance of that module.

I have considerable familiarity with this latter class of code control
systems (including having written one), but I have never before encountered
the former kind.

I am having some difficulty understanding just how it is supposed to work.
Everyone involved in the discussion apparently was quite familiar with them,
so the above is the best description of them supplied.  It leaves quite a
bit unanswered.

I will attempt to describe the system based on my understanding of it; I
would appreciate it if the original poster or someone equally competant
would review this, note any misconceptions, and answer my questions.  I will
be concentrating on "how to use the system", not "how the system works"; the
lines quoted above seem to cover that pretty well.

It appears that the main editing done by programmers using such a system is
the creation of "modsets".  These, in general, specify that certain lines
are to be inserted into a particular piece of source code.  (I gather some
systems allow more than one piece of source (source file or "deck") to be
updated with the same modset.  Maybe they all do?)  In addition, a modset
may specify that certain lines of code be deleted (deactivated), or that
certain lines which were previously deleted be restored.

I don't know how the lines to be inserted or deleted are identified.  I
would guess that each line has a line number, and that new lines are
inserted so that their line numbers remain in order.

It appears that traditionally, programmers directly created modsets, and
that it is a relatively new and far from universal thing for them to edit
the entire source file, and create the modfile mechanically.

It appears that the compilation step (in the development cycle) with such a
system is preceded by combining the programmer's modsets with the current
state of the code control system to produce the actual source to be compiled.

When a programmer is satisfied with his changes, he "signs in" his
modfile(s).  There may(?) be a review by someone before this actually
becomes part of the standard.

--------
It seems to me that the main problem with this kind of system is sorting out
simultaneous changes to the same piece of code.  It seems to me that the
advocates of this approach have become so used to dealing with this, that
they simply accept it as part of the system.  (In the comments I saw, there
were several suggestions for *mitigating* the problem, but no hint that it
was something one might want to *eliminate*.  It is a key advantage of the
SCCS-style approach that it does avoid the problem.)

I should note my own preference (not fully shared by my current co-workers).
I prefer an SCCS-style code control system, in conjuction with a convention
that there is only one entry point per file.  If, as is good for other
reasons as well, the functions are all kept relatively small, then all the
source files are small.  This means that two programmers trying to access
the same file at the same time are really trying to change the same code,
and one of them should wait for the other to finish.  (The inability for two
people to modify the same module at the same time is the characteristic
problem of this style of code control system, as integrating simultaneous
changes is the characteristic problem of the other.)

One *must* support this with some kind of include file system, so that
declarations can be consistent across modules.  The inclusion process need
not be regarded as the responsibility of the code control system, however.
(The include files themselves are source files to be maintained; but that is
another matter.)
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108