soft-eng@MITRE.ARPA.UUCP (06/05/88)
Soft-Eng Digest Sat, 4 May 88 V: Issue 9
Today's Topics:
Fortran follies (3 msgs)
Has anybody heard of "SABLE"?
More SCCS usage/Has anybody heard of "SABLE"? (2 msgs)
Paradigms for source control (6 msgs)
requirement specification
Source code control and DOS/LAN use
----------------------------------------------------------------------
Date: 13 May 88 03:25:48 GMT
From: portal!cup.portal.com!Paul_L_Schauble@uunet.uu.net
Subject: Fortran follies
I'm presently working on maintaining a Fortran compiler for a mainframe
computer manufacturer. I've had a few requests lately that I'd like to
throw out for opinions. Flames accepted too.
The machine in question is a segmented architecture. Each segment has its
own size and read/write permissions. Unfortunately, the hardware only
permits 512 segments visible at one time, so they can't be used for
individual arrays. The compiler has basic scalar optimization and automatic
vectorizing.
The first program is this
program main
real a(10000), b(10000)
...
call sub (a, b, 10000)
...
end
subroutine sub (a, b, n)
real a(1), b(1) <-- note dimensions
do 1 i = 1,n
1 a(i) = complex expression with a(i) and b(i)
....
The vectorizer looked at this and said that the maximum size of the array
is 1, therefore the maximum subscript is 1 and the vector temporary needed
in the subroutine only needs to be one word long. Of course, the real
vector size in n.
Second program is this
program main
...
common /one/ a(1)
common /two/ space(100 000)
common /tre/ alast
...
c calculate sizes of sub arrays
il1 = something
il2 = something else
il3 = yet more
c calculate starting points of sub arrays
ist1 = 1
ist2 = ist1 + il1
ist3 = ist2 + il2
c call working subroutine
call subbr (a(ist1), a(ist2), a(ist3), il1, il2, il3)
...
end
subroutine subbr(x, y, z, ilx, ily, ilz)
real x(1), y(1), z(1)
c long calculation using x, y, z as arrays ilx, ily, and ilz long
...
end
It's an interesting attempt at dynamic storage allocation. This is from the
CERN library, which is appearantly popular in Europe.
My problem is that the compiler puts each common block in its own segment,
so that all of the references to a produce segment protection faults.
Now, I know that both of these are non-standard. The last not only assumes
that all of common is in one segment but also assumes the order in which
the common blocks are laid down in memory. The technique would work if used
within a common block.
But they become significant issues to me when the customer bugs my
management to change the compiler to support these programs! They say that
they don't want to change their code.
I wonder of other compiler groups have hit these issues, and, if so, what
have you decided to do about them? Is there really a significant amount of
Fortran code out there that does this type of thing? Is it really possible
to do Fortran on a segmented architecture machine or do prevailing coding
practices rule it out? My thought is that these practices were ruled out of
the standard for very good reasons. But the customer is still always right.
------------------------------
Date: 15 May 88 00:20:48 GMT
From: trwrb!desint!geoff@bloom-beacon.MIT.EDU (Geoff Kuenning)
Subject: Fortran follies
In article <5377@cup.portal.com> Paul_L_Schauble@cup.portal.com writes:
> subroutine sub (a, b, n)
> real a(1), b(1) <-- note dimensions
Since variable dimensions have been part of standard Fortran for over ten
years, there is little excuse for using this older technique. However, it
used to be very popular, so I suppose the customer has an argument in
expecting the compiler to support it. Isn't the vectorizer smart enough
to see that the loop overruns the array?
> common /one/ a(1)
> common /two/ space(100 000)
> common /tre/ alast
This is totally unacceptable. In particular, I have used Fortran compilers
(actually linkers) that created common in order of declaration, and others
(e.g., DEC, I think) that sorted it into alphabetical order. This code
would not work on a DEC, since "alast" would precede "space". The standard
explicitly and loudly prohibits assumptions about the order of common. In
this case, I think you should tell your customer to read the standard and
stuff his program in a certain dark place.
------------------------------
Date: 17 May 88 14:43:57 GMT
From: pyramid!prls!philabs!pwa-b!mmintl!franka@decwrl.dec.com (Frank Adams)
Subject: Fortran follies
In article <5377@cup.portal.com> Paul_L_Schauble@cup.portal.com writes:
> real a(1), b(1) <-- note dimensions
At least one Fortran compiler I have used generated faster code with these
declarations than with the alternative a(n), b(n). The latter did some
initialization, even when it wasn't used.
I would recommend that you regard a dimension of 1 for an argument as
meaning that the dimension is undefined. It's not pretty, but it works.
------------------------------
Date: 8 May 88 03:04:01 GMT
From: vsi!friedl@uunet.uu.net (Stephen J. Friedl)
Subject: Has anybody heard of "SABLE"?
I wonder if anybody out there has any knowledge of a SABLE,
an SCCS-based configuration management system done by the same
AT&T group that built nmake. All I know is what I've indicated
here, and I'm interested in finding out more about it.
Related to this, I have found that naked SCCS is really not
suitable for doing even small projects and would like to find
something more. I have tried to build tools on top of SCCS and
am getting closer, but "The Right Way" has eluded me. Who knows
of good configuration management software based on SCCS? Even
ideas would be helpful.
------------------------------
Date: 12 May 88 01:34:22 GMT
From: mcvax!ace!konijn@uunet.uu.net (Erik van Konijnenburg)
Subject: More SCCS usage/Has anybody heard of "SABLE"?
In the recent summary of SCCS experiences, the following note
touches on one of the most important parts of version control:
keeping multiple files consistent.
> Charles Lambert <cl@datlog.co.uk>:
>
> ... Keep a System Description File that
> lists all the version-numbered sources needed for a correct build. This
> is simply a text document that has to be kept up to date. Since nobody
> remembers to keep documents up to date, it is wise to have your shell
> scripts do it automatically: every time someone deltas a file, the new
> version number gets written into the SDF.
And in article <647@vsi.UUCP>:
> Stephen J. Friedl <friedl@vsi.UUCP>:
>
> [ Question about Sable ]
>
> Related to this, I have found that naked SCCS is really not
> suitable for doing even small projects and would like to find
> something more. I have tried to build tools on top of SCCS and
> am getting closer, but "The Right Way" has eluded me. Who knows
> of good configuration management software based on SCCS? Even
> ideas would be helpful.
>
Using System Description Files is definitely the right direction for
version control. If these files have a fixed format, they can become
the basis of tools for practically all your source control.
-- It is possible to create source distributions automatically.
-- It is possible to produce a diff listing between two versions,
not of a single file, but of a complete product, complete
with the SCCS comments for all these changes.
-- Since the version of the snapshot file is a complete
identification of the product, it is sufficient to put the
version of the snapshot file in a product. This means you
no longer have to wade through pages of version strings to
get the one you are interested in.
-- By using SCCS simply as a "backend", much more flexibility is
available. For instance recursion: one single version number
identifies a complete distribution by giving the version
numbers of component parts, which give the version numbers of
component parts, and so on.
-- The version identification of a System Description File is
a great shorthand in communication between developers and
distributors: ``Version 6.25 of the C compiler does loop
invariant code moving, and could you do a trial UNIX
distribution and validation with it?''
Generating the distribution is then a matter of passing that
single version number to an extraction tool.
We built a system based on System Description Files, and find it
indispensable in keeping order in our distribution (several hundred
megabytes of kernels, uitilities, compilers, etc.).
There is a short paper on these version control tools and how they fit
in with validation, distribution generation, and software problem
report management. If you're interested in a copy, send mail to:
Eric van Konijnenburg, +31 20 646416
konijn@ace.nl
or ..!uunet!mcvax!ace!konijn
------------------------------
Date: 13 May 88 18:07:36 GMT
From: steinmetz!davidsen@itsgw.rpi.edu (William E. Davidsen Jr)
Subject: More SCCS usage/Has anybody heard of "SABLE"?
There is a technique I use for keeping things in line with SCCS. Perhaps
it's widely know and not used for some reason, but here it is.
Assume I'm at a production level, say 1.1, and am ready to make another
upgrade. First I pull an initial branch of all the files:
for n in s.*; do get -b $n; done
Now when I want to change something I do:
get -e -t s.whatever
which keeps things moving along the branch. When I delta I add comments
as always.
When I'm ready to update to the next production level (which in this
case will be 1.2) I just do:
for name in s.*
do
get -e -t -r1.1 $name
delta -y"Production version" $name
done
This will force all programs to have a version of 1.2, even if they
weren't changed.
I do the intermediate access with a script which does an extract if
there is no writable version, asks if I want to edit, asks if I want to
make, etc. Not elegant, but simple, easy to use, and reliable.
------------------------------
Date: 13 May 88 21:06:38 GMT
From: amdahl!pyramid!prls!philabs!pwa-b!mmintl!franka@ames.arpa (Frank Adams)
Subject: Paradigms for source control
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.)
------------------------------
Date: 16 May 88 23:56:06 GMT
From: amdahl!nsc!woolsey@ames.arpa (Jeff Woolsey)
Subject: Paradigms for source control
In article <2846@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
>I have considerable familiarity with this latter class of code control
(SCCS/RCS/PVCS et. al. (S/R/P hereinafter))
>systems (including having written one), but I have never before encountered
>the former kind.
(MODIFY/UPDATE/REVISE et. al. (M/U/R hereinafter))
>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.
Let me provide a simple, yet complete run-down of the M/U/R model.
The differences between the three are implementation issues, or small
variances within the paradigm.
There exists a Program Library (PL) consisting of source program
modules (decks), include files (common decks), named changes (modsets),
and a directory (for random access). The PL is a single file. Its
appeal is its integrity. Some effort is required to delete part of a
PL. If you have the PL, you have the whole source.
When you want to compile a program in a PL, you direct M/U/R to make
a compile file. This file is fed to the assembler or compiler as is.
Each line in it consists of the source line and a sequence number. The
sequence number is the name of the deck or modset followed by the
ordinal of that line within the deck or modset.
Common decks are the same as source decks except that they have a bit
set meaning that they can be included (at compile-file time) in another
source deck. Their original purpose was to hold all the COMMON
declarations in FORTRAN programs. You cannot generate a compile file
from just a common deck.
A modset consists of its name, the name of the deck to modify, and
insertion or deletion directives each followed by abritrarily long
sections of text. The text is inserted at the point the insertion or
deletion directives refer to. The insertion points are desginated as
modname.seqno or deckname.seqno, or just seqno if an original card in
the deck is desired. Deletion points can specify a range of lines.
The resemblance to drawers of punched card decks is the obvious
ancestry. It's probably obsolete, although lines are still pretty
pervasive as the unit of change in source control.
Modset creation generally means that you take a nice assembly/compiler
listing (made from the compile file with its sequence numbers) and go
off into a corner and mark it all up. Then you figure out which lines
are the insertion and deletion points, and type up your new text in
between directives. Then you reenter the edit-compile-debug loop.
Eventually the process was automated with tools analogous to diff -e.
If a source deck contained enough modsets such that not more than some
arbitrary number of lines were original code, it was said to need
resequencing. This is a fairly major event in the life of a deck, and
probably only happens twice. It destroys all the modset information
while retaining the net changes. The OS vendor would resequence decks
occasionally with new releases, and installation-specific modsets would
have to be converted because the line numbers changed. Locally-
developed programs could suffer resequencing, too.
A set of miscellaneous tools rounded things out with the ability to
extract everything back into source form and expunge modsets and other
mundane operations.
>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?)
For reference purposes, UPDATE/REVISE treat decks and modsets as the
same thing, whereas MODIFY distingushes them. This just dictates
whether there are "DECK" directives in your modset, and what the modset
sequence numbers are.
However, this ability of one named change to alter several related
source entities simultaneously and indivisibly is one of several
features I miss from the M/R/U paradigm. Another feature is
independent, non-monotonic changes, any particular collection of which
may be selected to build a particular flavor of product. (analogous to
#ifdef FEATURE ) The third is PL integrity (mentioned above).
>In addition, a modset
>may specify that certain lines of code be deleted (deactivated), or that
>certain lines which were previously deleted be restored.
Restoring deleted lines, though supported, was a no-no as far as OS
support was concerned. A real good way to cause dependencies and other
conflicts. You were to accomplish the same net effect by inserting new
copies of the orignally-deleted lines. COMPARE (diff -e) would do it
this way.
Joe User, in complete control of his own PLs, however, is perfectly
welcome to create conflicts and dependencies, as long as he can deal
with the results.
>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.
By name.number . "number" is always sequential, and there are no
fractions. Each change (modset) has a unique name (modname). The
number of a line never changes, but it could be deactivated, and an
identical line with a different modname and number could replace it.
This is one reason why resequencing is so traumatic.
>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.
"relatively" is relative here. This basically describes the state of
affairs four years ago and more at a large university running
mainframes. Eventually each programmer would discover that COMPARE
could generate modsets.
>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.
Essentially correct. It is a special case. Even in the case of
product installation, a compile file is built. The PL is really a list
of lines, each of which contains a pointer to each modset that
referenced it and how (active or not). When applying a modset,
another set of these pointers is built, and making the compile file
involves looking at the list of pointers to see the net effect. If the
line is now active, it is copied to the compile file.
>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.
For the OS with local changes, yes. The system programmers "submit"
their modsets to a coordinator, who then figured out which (if any)
modsets conflicted or depended upon one another or the same thing.
(This process was eventually automated.) The submittors were then
asked to reconcile their modsets to resolve these problems. Then the
whole mess was printed and circulated for code review.
>--------
>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.)
So what does a programmer do while waiting for the code to be
available? Go to the listings on the shelf and work out the changes
based on that version. Then when the source is free, apply the
changes. Surprise, reality has changed.
But there are usually many ways to subvert the intentions of a source
code control system.
>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.)
Usually the integration is painless, if the two programmers are doing
different things and don't bump into each 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.)
Indeed. It just so happend that M/U/R provided the include mechanism
because the included portions are part of the program library. They could
also be included from another such library, if needed (usually the case
for the system common decks).
------------------------------
Date: 16 May 88 22:19:36 GMT
From: portal!cup.portal.com!jxh@uunet.uu.net
Subject: Paradigms for source control
In <2846@mmintl.UUCP>, Frank Adams (franka@mmintl.UUCP) writes:
>>...a descendent of UPDATE/MODIFY from the Cybers...
>It leaves quite a bit unanswered.
Yes, sorry about that. Your observation that the original parties to the
discussion were familiar with UPDATE/MODIFY is quite true. I will try to
summarize the relevant facts about that universe (or perhaps Dan Germann or
Jeff Woolsey, who used it much more than did I); but your "understanding"
will stand for the moment. It's pretty good.
>I will attempt to describe the system based on my understanding of it.
>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.
Lines were identified by a deckname or modname, followed by a sequence number,
e.g. DECK.1, DECK.2, ..., DECK.999. Sequence numbers were assigned beginning
with 1 for each different name. Thus: DECK.1, DECK.2, MODSET.1, DECK.3 ... .
The order of these lines in the Program Library (PL) defined the sequence of
lines in the actual source. Modsets consisted of directives, such as
*DELETE DECK.1,DECK.4 <deletes range of lines, inclusive>
*INSERT DECK.2 <inserts following lines after DECK.2, assigning
insertion text sequence numbers to each: MODSET.1, MODSET.2 >
more insertion text
*more directives
>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.
Just so. A separate text-comparison program was given the ability to
express differences as a set of directives suitable for feeding to
UPDATE for just this purpose. Actually, this may be more universal than I
thought, as more-capable editors become available under NOS.
>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.
You're batting 1.000. This step takes the PLs and modsets, and creates the
COMPILE file, which is the modified source. COMPILE was typically an
alternate default filename on, e.g., the assembler, to eliminate steps from
your batch job. (Egad!)
>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.
Someone else (Messrs. Woolsey or Germann) should elaborate on the procedural
aspects of source control that developed in their shop. For the moment,
let me simply say "code review" and "proposed modset" and hope that gives
the right impression. I think the fact that modsets were "hard" to
introduce into the database permanently had a positive effect on quality,
as they were subjected to tremendous scrutiny.
--------
>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.)
Well. Here we go. I would settle for *mitigating* if it meant I could get
named modsets. *Eliminating* would be nice, but implies the (imho) too-
restrictive locking of source files. How about *automating* the process of
identifying (and perhaps resolving) conflicts?
>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.)
It is true that, on the Cybers, programs tended to be huge and monolithic
(not because of bad programming practice but because of institutional biases
such as *LOCAL FILE LIMIT*); whereas small-computer programs tend to have
lots of small parts. I applaud modularity when it is APPROPRIATE FOR THE
PROGRAM, not imposed by outside forces such as making source control easier,
or making things compile faster (however worthy those goals certainly are).
I detect a bias toward C programs, where all functions are at the same scope
level; in this case, putting them into separate files makes sense. However,
Modula-2 programs tend to have many routines within a module; and this tends
to make single modules rather monolithic themselves. (I have broken a single
module into several because of an implementation restriction, when I would
have preferred keeping it in one piece to ensure data integrity of private
objects.)
Making simultaneous changes to one module might easily mean implementing
two completely different and, conceptually, independent modifications. A
source control program should allow me to modify the top while you're
working on the bottom; if there is no real conflict, then file-locking
should not preclude my getting some useful work done while you,
presumably, do the same. PVCS tries to allow this by "branching," which
seems simply to be a cop-out, the program recognizing that a conflict is
(potentially) being created that will have to be sorted out later when the
two branches "merge."
Furthermore, my change might remain unrelated to yours forever. Perhaps I
want to apply a temporary change to see what would happen. I could, of
course, do this by making a local copy of the source file in question, and
do as I please with it, but if my prattlings in my sandbox become worthwhile
I would like to be able to put them into the real source for everyone's
benefit without having to reconstruct what I did. A modset from the common
base source describes my actions succinctly, and can be stored in rather less
space. (Flame off. Sorry. I really don't know the first thing about SCCS,
so if all this is possible there simply by sleight of hand, please let me
know).
Oh, this is exciting! I thought this newsgroup would be a good place for
this discussion!
P.S. My boss just walked into my office brandishing a copy of the glossy
for PVCS and, in a moment of candor, I told him that we should get it and
use it; that it is, at least, a giant step in the right direction, even
if it isn't quite all I hoped for. Of course, we should all get Suns and
avoid the PC problems altogether, but he's not prepared to hear that.
------------------------------
Date: 19 May 88 02:32:11 GMT
From: garth!smryan@unix.sri.com (Steven Ryan)
Subject: Paradigms for source control
Gee, I never thought anybody outside of CDC knew of MODIFY (NOS), UPDATE
(NOS/BE, NOS, VSOS), and now SCU (NOS/VE).
All of the source code is stored in what is called a program (or source)
library (called the PL). The program library is divided into decks (as in
punched cards) which are divided into individual lines. A deck can be module,
data structure, or whatever conceptual chunk you wish to use. Each deck
has a unique name. MODIFY maintains last modification date for each deck.
A line is a line of source text, an identifier, and a modification history.
UPDATE line identifiers are unique across the PL. MODIFY identifiers are only
unique within the deck. Lines in the original deck have identifiers like
deckname.1, deckname.2, ... Lines subsequently inserted have identifiers
like id.1, id.2, ... A line can be deactivated (deleted), activated,
deactivated, et cetera, an arbritrary number of times as the result of a
series idents (changes). The modification history attached to each line
refers to successive activations/deactivations and which ident did it.
Only lines which are currently activated are listed. All the deleted lines
are still there, though, which is useful in the whoops! mode of programming.
Once a group of idents is permanently added to the PL and the system built,
if you discover, whoops! ident F7B022 just broke the entire vectoriser, you
just do a *YANK F7B022 to magically erase F7B022 from the system. Actually,
it goes through the modification history and adds an activation to lines
deleted by F7B022 and deactivation to lines inserted. As long as subsequent
idents do not refer to the same lines, in principle, F7B022 can be *YANKed
and *UNYANKed as many times as necessary to get it right.
Programmers have to handcode the changes line by line, not very pleasant,
unless SCOOP is working. But having all the line changes in an ident has
the advantage of making the changes very visible, simplifying the code
reviews. Idents contain both editting commands and comments which have the
programmers name, other identification, and explanation of the change and
its reason all in one bundle.
Far from making collisions in the source more burdensome, it usually makes
them less so. Two separate programmers can modify the same deck without error
as long as they modify distinct lines. Generally safe. The project leader
is suppose to review all idents for interferences but this includes
interferences which might be on separate decks.
All idents for a PL are collected and applied in mass for each build cycle.
At this point, if two idents affect the same line, MODIFY/UPDATE squeals
loudly, and the project adjusts for the unexpected overlap. This does
happen, but usually like once a year and takes a five-minute change.
------------------------------
Date: 21 May 88 01:00:13 GMT
From: necntc!drilex!dricej@ames.arpa (Craig Jackson)
Subject: Paradigms for source control
This is a discussion that is near and dear to my heart. While the *CS
programs have many advantages, there are a few things which I sorely
miss from 'mainframe' source code control systems, (of which MODIFY/UPDATE
is one).
The biggest thing that I miss in the Unix world is the ability to easily
have independent development on a common body of source by two sets
of programmers in two locations. The most common case of this is
a vendor sending out source updates, and a local site making patches.
In the Unix world, each time AT&T comes out with a release, all of the
System V vendors need to re-do their port. Now Unix is portable, but it
isn't so portable that unnecessary ports are to be desired. In a
system such as M/U, there is a unique identifier attached to each line
of the source file. Two modsets can affect different regions of the file
with no change whatsoever.
In the unix world, diff -c & patch attempt to provide the same utility.
However, if there isn't enough common context, things fall apart. Also,
diff -c only comes from Berkeley; you're left to the net to pick up
diffc if you're on a USG system. 'patch' only comes from the net in
the first place.
You may denigrate the need for 'line numbers' or 'line identifiers' in
systems such as M/U. Yes, they are extra baggage. Yes, they do go
along with such things as fixed-length source lines and source listings.
Yes, they do imply occasional resequencing. However, by uniquely
identifying each line, it's possible to unabiguously talk about precise
regions of code. I only wish I could give each token in the source file
a unique identifier, but it isn't really feasible.
------------------------------
Date: 19 May 88 22:37:11 GMT
From: portal!cup.portal.com!jxh@uunet.uu.net
Subject: Paradigms for source control
I just got my copy of Polytron's PVCS (Polytron Version Control System).
I will be launching myself into it shortly. When I surface again, I'll
bring a full report.
------------------------------
Date: 17 May 88 22:42:23 GMT
From: uhccux!cs661s02@humu.nosc.mil (Cs661s02)
Subject: requirement specification
I looking for references in generating requirement specification
document. Thanks in advance.
------------------------------
Date: 13 May 88 20:15:35 GMT
From: ucsdhub!hp-sdd!ncr-sd!ncrlnk!fenix!kcby@ucsd.edu (kcby)
Subject: Source code control and DOS/LAN use
We have recently come up with a source code control problem that perhaps one
of you has already tackled.
Our development environment consists of networked PC's running DOS with a
project file server. (If it makes any difference, the network is a Banyan
token-ring LAN.) Our plan was to keep source code on the server, and do
compilations and links from the individual PC's. Our development language
will be C++... and herin lies the problem. The C++ pre-processor
(Advantage) requires all of the 640K of memory beyond a standard DOS load
to compile a program of any size - meaning we can not have the network
driver resident which would allow connection to the server (and the
released source files which might need to be included) while the compile is
occurring.
Because of the memory requirements, it looks like the source will have to
be maintained on each PC. So... does anyone have any suggestions on how we
keep the files on multiple PC's up to date? Copying the files from the
server each time we are ready to compile seems like it would impact the
compile time too severely. Doing nightly distribution of sources would be
reasonable, except the file server is just that... not a "central"
processor, so there's no "controller" for the network.
And, in thinking about this, I started to wonder how many organizations are
now doing development with networked PC's (and without a "central" project
processor). If you are involved in using a development environment with
networked PC's, I'd like to hear from you. Particularly I'm interested in
knowing:
a) what kind of network/server arrangement you use
(including whether you use DOS or XENIX)
b) whether you use a "central" or "controlling" processor
b) where you maintain your source code (central or distributed)
c) how you control access / updates to source code
(e.g. what kind of change control do you use)
d) whether you've had a similar problem to solve regarding
memory use if you're running under DOS and if so
how you solved it
------------------------------
End of Soft-Eng Digest
******************************