Path: utzoo!attcan!uunet!portal!cup.portal.com!jxh From: jxh@cup.portal.com Newsgroups: comp.software-eng Subject: Re: Paradigms for source control Message-ID: <5504@cup.portal.com> Date: 16 May 88 22:19:36 GMT References: <5291@cup.portal.com> <2846@mmintl.UUCP> Organization: The Portal System (TM) Lines: 126 XPortal-User-Id: 1.1001.4342 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 *INSERT DECK.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. Not yet. -- Jim Hickstein, VSAT Systems, Inc., San Jose CA jxh@cup.portal.com ...!sun!portal!cup.portal.com