cl@dlhpedg.co.uk (Charles Lambert) (01/12/88)
This is a reposting of an article I first posted two months ago. Two
correspondents finally got through to me to say my reply path was garbage.
(Bill Jones, I'm preparing a reply to your message)
The "Reply-To" line in this header should be correct now, so I'm trying
again. If replies fail again, my explicit UUCP path from the UK backbone
machine (ukc) is !stl!datlog!dlhpedg!cl
---------------------------------------------------------------------------
(was: "Development Control: terminology needed")
We have been developing tools and procedures (for use within our organisation)
to control those periods of intense development when many people are working
on a product at once, several of them perhaps altering the same source file
concurrently for different reasons. Now I have to produce documents and I
need good terms to make the concepts clear and easy to discuss. The
vocabulary that has grown up around the prototype is rather inconsistent
and misleading.
In my experience, well chosen terms improve people's comprehension of a
system dramatically, while fuzzy ones litter the mind with misconceptions.
So I hope that some of the technically literate out there will help me.
Let me outline what we have and ask anyone with constructive suggestions
to mail them to me.
ORGANISATION
------------
Partition
---------
The development community is divided into teams, each working on some
functional aspect of the same product. There's the first slippery term:
"product". It can mean either the final absolute object, or that object
and all the components (e.g. source files) from which it is built.
There is a hierarchy (tree, structure) of directories that will contain this
product (i.e. all the components and the final object).
There is one public copy of the above hierarchy that is fully populated;
it contains a copy of every component, each one being the correct version
to build the latest stable version of the product.
Each development team has a private instance of the directory hierarchy
in which they keep copies of the components they have altered. They do
not keep copies of components they have not altered; the building tool
is capable of finding those in the public copy. The private instance
is said to be sparsely populated.
Here we need a term for an instance of the directory hierarchy, so that we
can talk about "our ***," "your ****," or "the public ***". At the moment,
we call it a "build", after the mechanical engineering term referring to a
schedule of components. This is a bad term because
i) it is a verb doing service for a noun,
ii) we need the verb anyway ("which build did you build?"),
iii) it is not evocative - it doesn't portray what it means.
Association
-----------
Now an extra degree of complexity. Besides the public "build" and the
"builds" assigned to each functional task, a group of teams may share
an intermediate "build" where they deposit finished work that they all
want to incorporate, but is not for general release yet. So, when one
of the teams builds the product, the building tool must search a vector
of "builds" starting with the team's private one, then the shared one
and finally the public one. We have called this vector a "view" (with
acknowledgements to Erickson and Pellegrin of Bell Labs [1]).
Some of our developers have taken to referring to a "build" as a "view"
because:
i) the view is an invariant attribute of the "build" - in our
system, once you have declared the antecedence of the version
you're working on you stay with it;
ii) it rather neatly describes what a "build" is for - it is a place
from which you get an alternative view of the product.
However, we need separate terms to differentiate between an individual
"build" and the ordered summation of several "builds"; I think "view"
serves the latter purpose best.
[By the way: we rejected the term "node", as an alternative to "build",
because of its strong association with network topology and hence with
communications]
You will see that "views" converge from team "builds" through shared
"builds" to the public "build". We might use the term "branch" instead
of "build", but we would risk confusion with the terminology of the
Source Code Control System that maintains a history of changes for each
source file.
OPERATIONS
----------
Distribution
------------
When a development team needs to alter a component, they take a copy from
the first "build" in the view that contains a version of that component;
it may be copied from a shared "build" if a cooperating team has already
altered it, or it may be copied from the public build. After they have
started work on their copy, someone may alter the version from which
they started - their "antecedent" version. Eventually, the team must
combine that alteration with their own so that a unified version of the
file can be deposited in the shared or public "build".
We have called this operation "reconciliation"; clumsy - any offers?
Integration
-----------
When a team completes a functional development, it deposits the completed
work further down the view, where cooperating teams will see it. This
may involve combining their new version of a component with another version
that is already there. This is called "integration". It may appear to
be the same as reconciliation but there is an important distinction:
"reconciliation" takes place in the reconciler's "build" - several
"builds" may be "reconciled" with changes that have gone into a shared one
but the reconciled versions remain private and different from one another;
"integration" takes place further down the integrator's view where it
come within other views (and may cause other "builds" to need reconciliation).
REFERENCES
----------
[1] "Build - A Software Construction Tool" V. B. Erickson and J. F. Pellegrin;
AT&T Bell Laboratories Technical Journal, Vol. 63 No. 6 (July-August 1984)
pp. 1049-1059
-------------------------------------------------------------------------------
I will be glad to receive any pertinent criticism of the style, terminology
or clarity of the above.
--------------------
Charles Lambert; cl@datlog.co.ukstank@orca.TEK.COM (Stan Kalinowski) (01/18/88)
Let me start off by making an observation. One can tell that the science of software engineering is still in its infancy. It seems that as much time is spent defining new software engineering terms for existing concepts as is spent on solving the engineering problems. Why not use the existing software engineering terms? Perhaps I'm overly critical, but it seems that every new researcher sees the field of software engineering as an opportunity and tries to glean a bit of imortality by being the first to coin the term (substitute you favorite buzzword here). I find it difficult to believe that so many people are simply unaware that terms already exist to describe most software activities. By the way Mr. Lambert, I'm not necessarily picking on you personally, but hoo-boy, you scored a direct hit on one of my hot buttons! Now that I have dispensed with the knee-jerk reaction, perhaps it was just a jerk reaction :-), let me describe the jargon my working group would use for what you describe, perhaps it will help. In article <368@dlhpedg.co.uk> cl@datlog.co.uk (Charles Lambert) writes: . . (text was trimmed and refilled for brievity but it's still long.) . >We have been developing tools and procedures (for use within our >organisation) to control those periods of intense development when >many people are working on a product at once, several of them >perhaps altering the same source file concurrently for different >reasons. Now I have to produce documents and I need good terms to >make the concepts clear and easy to discuss. The vocabulary that >has grown up around the prototype is rather inconsistent and >misleading. In my experience, well chosen terms improve people's >comprehension of a system dramatically, while fuzzy ones litter the >mind with misconceptions. So I hope that some of the technically >literate out there will help me. It sounds like you are attempting to describe your "development control" scheme to people that are not familiar with software jargon. I think that inventing new terms would probably compound your problem. I think it would be better to explain the existing terminology rather than create an additional learning barrier. Even if your audience is familiar with the commonly used software nomenclature, it probably wouldn't hurt to define your terms in an appendix. (I think new terms are invented by people too lazy to learn how to use the existing ones, probably a fallout of the "software cannot be re-used mentality", but that's just my opinion.) >The development community is divided into teams, each working on >some functional aspect of the same product. There's the first >slippery term: "product". It can mean either the final absolute >object, or that object and all the components (e.g. source files) >from which it is built. Around here, we call the thing we sell to customers a "product" and the stuff that engineers produce is called software. If we want to distinguish software that is used in our "product" as opposed to software tools, we use the phrase "product software". >There is a hierarchy (tree, structure) of directories that will >contain this product (i.e. all the components and the final object). We call that a "build tree" or, more specifically, a "build directory-tree". (I don't know if Merriam Webster would approve of using dual attributive nouns like "build directory", but what-the-heck, it works.) >There is one public copy of the above hierarchy that is fully >populated; it contains a copy of every component, each one being the >correct version to build the latest stable version of the product. We would call that the "release" source directory. >Each development team has a private instance of the directory >hierarchy in which they keep copies of the components they have >altered. They do not keep copies of components they have not >altered; the building tool is capable of finding those in the public >copy. The private instance is said to be sparsely populated. We call the private instances "private build-trees" or "experimental build-trees". >Here we need a term for an instance of the directory hierarchy, so >that we can talk about "our ***," "your ****," or "the public ***". >At the moment, we call it a "build", after the mechanical >engineering term referring to a schedule of components. This is a >bad term because > >i) it is a verb doing service for a noun, >ii) we need the verb anyway ("which build did you build?"), >iii) it is not evocative - it doesn't portray what it means. I can see where the confusion could arise. We also use the term "build" to refer to the compiled/assembled/linked system, but we call the "schedule of materials" a "bill of materials" or, more briefly, "BOM". This expression comes from manufacturing terminology. To me, it evokes the image of software modules specified in the BOM being pulled together on an assembly line, to create a given "build" of the product. We do not think of the directory tree itself as being the bill of materials, we maintain a separate file that lists what's in the build. The term "build" is used often around here and people seem to have no trouble gathering the meaning from the context in which its used. I avoid cases like number ii) above, I would probably be more specific and say "Which configuration did you make?" when I what to know what sources or compilation switches were used in the build, peopl usuall respond with a product codename as an answer. >Now an extra degree of complexity. Besides the public "build" and >the "builds" assigned to each functional task, a group of teams may >share an intermediate "build" where they deposit finished work that >they all want to incorporate, but is not for general release yet. We use the word "release" to indicate a build that must be coordinated with other groups. If we need to be more descriptive we can tack on something like "evaluation" or "beta test" to help describe the intended use of the build. We also assign a single revision/version identifier to identify the build as a whole, this makes tracking the builds simple. >So, when one of the teams builds the product, the building tool must >search a vector of "builds" starting with the team's private one, >then the shared one and finally the public one. We have called this >vector a "view" (with acknowledgements to Erickson and Pellegrin of >Bell Labs [1]). It seems to me that the term "view" is just as bad (if not worse) than the term "build". The word "view" also has several meanings. It can be what one sees from the top of a mountain, it can be the transformed image found on a graphics display, or it can be a projection of an object on an engineering drawing. At least with the term "build" you have the manufacturing analogy, which I think *IS* evocative. >Some of our developers have taken to referring to a "build" as a "view" >because: >i) the view is an invariant attribute of the "build" - in our > system, once you have declared the antecedence of the version > you're working on you stay with it; >ii) it rather neatly describes what a "build" is for - it is a place > from which you get an alternative view of the product. I don't see the analogy supporting i) at all, and the support for ii) is weak at best. By the way, we avoid maintaining multiple, actively used, versions of a given module's codee whenever possible. We have found that it is very difficult to propagate bug fixes common to several product lines to each product without having to "un-fix" some bugs that are unique to a product. Also, maintaining functional compatibility is made more difficult by parallel versions of source code. We choose, instead, to maintain one code base for the products (where possible) and do product version control via conditional compilation. (If you have a better answer to this problem, I'd like to hear it.) >When a development team needs to alter a component, they take a copy >from the first "build" in the view that contains a version of that >component; it may be copied from a shared "build" if a cooperating >team has already altered it, or it may be copied from the public >build. After they have started work on their copy, someone may >alter the version from which they started - their "antecedent" >version. Eventually, the team must combine that alteration with >their own so that a unified version of the file can be deposited in >the shared or public "build". > >We have called this operation "reconciliation"; clumsy - any offers? Yeah, call it "programmer's hell". In my experience, communication generally breaks down between between parallel code developers. This is usually due to schedule demands placed on the engineer. Even when communication is mandated by management through the use of inter-project design reviews, the reviewer often does not realize the impact the proposed changes will have. This frequently results in expensive redesign and rework when the "reconciliation" happens. Until I find a better answer, I think a single designer should maintain a given module for all products. This also forces the designer to consider inter-product functional compatibility/consistancy, which is VERY important these days. Well, I've probably insulted just about everybody on the net by now, but I feel better. :-) I hope what I had to say helps someone out there avoid what I learned the hard way. (It probably won't though, most people would have hit "N" as soon as they saw "long" in the subject line. They probably said something like "Oh God, not another one of those software engineering nut's ranting again.". -- US Mail: Stan Kalinowski, Tektronix, Inc. Information Display Group, Graphics Workstations Division PO Box 1000, MS 61-028, Wilsonville OR 97070 Phone:(503)-685-2458 uucp: {ucbvax,decvax,ihnp4,allegra,uw-beaver}!tektronix!orca!stank
hollombe@ttidca.TTI.COM (The Polymath) (01/21/88)
In article <2457@orca.TEK.COM> stank@orca.UUCP (Stan Kalinowski) writes: > >When a development team needs to alter a component, they take a copy > >from the first "build" in the view that contains a version of that > >component; it may be copied from a shared "build" if a cooperating > >team has already altered it, or it may be copied from the public > >build. After they have started work on their copy, someone may > >alter the version from which they started - their "antecedent" > >version. Eventually, the team must combine that alteration with > >their own so that a unified version of the file can be deposited in > >the shared or public "build". > > > >We have called this operation "reconciliation"; clumsy - any offers? > >Yeah, call it "programmer's hell". ... Better yet, call it "unnecessary". I've run into this situation in several shops where people simply didn't know better (not that there was any excuse for that). The solution is a configuration management system wherein only one person can work on a module at a time. In order to work on the module they have to check it out of the system in such a way that no one else can check it out until it's been checked in again. I've worked with systems that handle this automatically and I've set up systems where it was handled manually because nothing else was available. However you handle it, it's absolutely essential to a rational code maintenance system. Letting two people work on the same module in parallel, even if they're office mates, is almost certain to cause conflicts and rework, sooner or later. One at a time will save time in the long run. -- The Polymath (aka: Jerry Hollombe, hollombe@TTI.COM) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax|trwrb}!ttidca!hollombe
jonesb@calgary.UUCP (Bill Jones) (01/27/88)
In article <1713@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes: >In article <2457@orca.TEK.COM> stank@orca.UUCP (Stan Kalinowski) writes: >>In article <368@dlhpedg.co.uk> cl@dlhpedg.co.uk (Charles Lambert) writes: >>>We have called this operation "reconciliation"; clumsy - any offers? >>Yeah, call it "programmer's hell". ... >Better yet, call it "unnecessary". ... >The solution is a configuration management system >wherein only one person can work on a module at a time. In order to work >on the module they have to check it out of the system in such a way that >no one else can check it out until it's been checked in again. Okay, suppose your company is working on the next release of a product already in the field. An important customer reports a critical bug, and you find that the fix for it involves several modules which are checked out and being modified for the next release. Should that team be held up while you yank back the modules and figure out how to recompose the customer's configuration? Or do you mean to tell the customer that his bug can't be fixed until the next release is out? Parallel development paths may have the danger of conflict, but proper management and tool support can minimize it. I would be interested in hearing of any non-parallel system which cleanly supports both new development and maintenance of past releases.
geoff@desint.UUCP (Geoff Kuenning) (02/01/88)
In article <1315@vaxb.calgary.UUCP> jonesb@calgary.UUCP (Bill Jones) writes: > Okay, suppose your company is working on the next release of a product > already in the field. An important customer reports a critical bug, > ... > > Parallel development paths may have the danger of conflict, but proper > management and tool support can minimize it. I would be interested in > hearing of any non-parallel system which cleanly supports both new > development and maintenance of past releases. RCS supports this very nicely; you simply create a branch for the bug fix while development continues on the main path. RCS even provides the "-j" switch (admittedly a very hard switch to use correctly) to help you merge that fix back into the main branch later. (You can also use System V's sdiff program, or Larry Wall's patch program, to achieve similar results). I believe you can also do this with SCCS, though I haven't personally created an SCCS branch while another revision was actually checked out. -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
hollombe@ttidca.TTI.COM (The Polymath) (02/02/88)
In article <1315@vaxb.calgary.UUCP> jonesb@calgary.UUCP (Bill Jones) writes:
=Okay, suppose your company is working on the next release of a product
=already in the field. An important customer reports a critical bug,
=and you find that the fix for it involves several modules which are
=checked out and being modified for the next release. Should that team
=be held up while you yank back the modules and figure out how to
=recompose the customer's configuration? Or do you mean to tell the
=customer that his bug can't be fixed until the next release is out?
Neither. You ship the customer(s) a temporary patch for the existing
code. Patched versions of code don't get checked in (but the patches do,
for the record). Then you include the fix in the next release (based on
the patch). This causes minimal disruption to the work on the next
release.
If you're working in a high-level language you probably aren't going to
literally patch the code, but the process can logically be treated in the
same way. The people working on the release still have only one version
of each module to work with, and the patch becomes an addition to their
task list.
--
The Polymath (aka: Jerry Hollombe, hollombe@TTI.COM) Illegitimati Nil
Citicorp(+)TTI Carborundum
3100 Ocean Park Blvd. (213) 452-9191, x2483
Santa Monica, CA 90405 {csun|philabs|psivax|trwrb}!ttidca!hollombeg-rh@cca.CCA.COM (Richard Harter) (02/02/88)
In article <1664@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >In article <1315@vaxb.calgary.UUCP> jonesb@calgary.UUCP (Bill Jones) writes: > >> Okay, suppose your company is working on the next release of a product >> already in the field. An important customer reports a critical bug, >> ... >> >> Parallel development paths may have the danger of conflict, but proper >> management and tool support can minimize it. I would be interested in >> hearing of any non-parallel system which cleanly supports both new >> development and maintenance of past releases. Although an adequate tool set is critical, the most important factor is proper management. I can speak to this from some experience since SMDS is in the business -- our product is a software management system and our customers are software managers and CM people in companies of a variety of sizes -- and we get to see what works and doesn't work. What happens in most organizations is that development happens first, an ad hoc system is worked out by the developers, CM, QA, and customer support get tacked on as an after thought, and things get rather messy after a while. Once things get sufficiently entrenched it becomes very hard to restore order. I don't want to go into a lot of detail, but I will make two observations. (1) Once you have an existing organization, there is a political problem. (2) Good CM and QA require organizational commitment; they are not an add on. As to parallel development -- "new development and maintenance of past releases" is inherently parallel. Actually "parallel" is a misleading term. It suggests independent paths of equal priority. What really goes on is that one has a mainline product(s) with variants. The variants may be enduring (separate supportable releases) or transient (development efforts). What one tries to do is, so to speak, minimize the distance between variants and the mainline. From the developers perspective, however, the process is linear. The developer ordinarily is working with a single variant that is evolving over time. Going back to previous versions, and merging changes are useful, but not essential. Development is implicitly constrained by the need to keep the distance between the variant and the mainline small. A lot of 'good software practice' is really an expression of this requirement. > >RCS supports this very nicely; you simply create a branch for the bug fix >while development continues on the main path. RCS even provides the "-j" >switch (admittedly a very hard switch to use correctly) to help you merge >that fix back into the main branch later. (You can also use System V's >sdiff program, or Larry Wall's patch program, to achieve similar results). > >I believe you can also do this with SCCS, though I haven't personally >created an SCCS branch while another revision was actually checked out. One should, of course, understand that a tool for merging is not the same thing as successfully merging. Merging, at the mechanical level, is not terribly difficult. The real problem is that the merged software is neither fish nor fowl; there is an interaction between the two lines that were merged that is not present in either parent line. Ideally one creates lines that are orthogonal; i.e. the changes in line A are independent of the changes in line B. Arranging orthogonality is a part of good software management. In practice complete orthoganality cannot be ensured, and the merge process must take this into account. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
cl@datlog.co.uk (Charles Lambert) (02/02/88)
> [tektronix!orca!stank@ucbvax.Berkeley.EDU (Stan Kalinowski) writes:] > > [Several criticisms of the quest for terminology] We're not really in dispute, here. I'm sure that the engineering and manufacturing disciplines have produced a wealth of good terms; I'm simply not aware of them all nor convinced that the ones I know are most appropriate. I have three criteria for a good term: it should be concise, unambiguous and evocative. >We call that a "build tree" or, more specifically, a "build >directory-tree". (I don't know if Merriam Webster would approve of >using dual attributive nouns > ... >We call the private instances "private build-trees" or "experimental >build-trees". This is just the kind of linguistic forest I want to avoid; it makes for congested documents and long-winded speech. Any noun requiring that degree of qualification is ambiguous, and the resulting term is not concise. > > [...3 reasons why I dislike the term "build"...] > >i) it is a verb doing service for a noun, > >ii) we need the verb anyway ("which build did you build?"), > >iii) it is not evocative - it doesn't portray what it means. > >I avoid cases like number ii) above, I would probably be more specific >and say "Which configuration did you make?" This further demonstrates that it is a bad term - it must be paraphrased for clear communication. >It seems to me that the term "view" is just as bad (if not worse) than >the term "build". The word "view" also has several meanings... >...or it can be a projection of an object on an engineering drawing. "View" seems evocative for just that reason. It is the projection of two or more (sparsely populated) "builds" to produce a superimposed collection. A "build" is to a "view" what a scalar element is to a vector. This is essential to the way we share stable (or beta-testable) sources. >By the way, we avoid maintaining multiple, actively >used, versions of a given module's codee whenever possible. We have >found that it is very difficult to propagate bug fixes common to >several product lines to each product without having to "un-fix" some >bugs that are unique to a product. Avoiding multiple concurrent changes to the same module is ideal - an ideal we are unable to maintain in practice. The mechanisms of source-sharing and "reconciliation" in our prototype system are intended to take the pain out of propagating fixes amongst product lines and amongst concurrent developments of the same line. Most of the responses I have received to the latter idea suggest that it is hopelessly ambitious. Our experience doesn't yet support that view. There are some subtle complexities in merging concurrent developments but we are presently managing by a combination of automation (using SCCS delta inclusion) and assisted inspection. We have not yet exhausted the potential for automatic assistance. -------------------- Charles Lambert Data Logic UK, Harrow, England.
shap@bunker.UUCP (Joseph D. Shapiro) (02/03/88)
In article <1664@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >In article <1315@vaxb.calgary.UUCP> jonesb@calgary.UUCP (Bill Jones) writes: > >> Okay, suppose your company is working on the next release of a product >> already in the field. An important customer reports a critical bug, >> ... >> management and tool support can minimize it. I would be interested in >> hearing of any non-parallel system which cleanly supports both new >> development and maintenance of past releases. > >RCS supports this very nicely; you simply create a branch for the bug fix >while development continues on the main path. RCS even provides the "-j" >switch (admittedly a very hard switch to use correctly) to help you merge >... >I believe you can also do this with SCCS, though I haven't personally >created an SCCS branch while another revision was actually checked out. \ yes, SCCS allows different revisions to be checked out concurrently. there is also a means to apply the same fix to different revisions, as follows: get -e -r4.1.1.2 s.x.c # gets 4.1.1.2 for editing vi x.c # make your changes delta s.x.c # creates 4.1.1.3 (assuming 4.1.1.2 was a 'leaf') get -e -r4.2 -i4.1.1.3 s.x.c # gets 4.2, includes 4.1.1.3 changes delta s.x.c # creates 4.3 (assuming 4.2 was a leaf), with 4.1.1.3 changes. Note that the second get could complain about conflicts, e.g. overlapping areas of change on the different branches. -- -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Joe Shapiro "My other car is a turbo... Bunker Ramo Olivetti too." {decvax,yale,philabs,oliveb}!bunker!shap
tim@brspyr1.BRS.Com (Tim Northrup) (02/05/88)
in article <1664@desint.UUCP>, geoff@desint.UUCP (Geoff Kuenning) says: | | In article <1315@vaxb.calgary.UUCP> jonesb@calgary.UUCP (Bill Jones) writes: | |> Okay, suppose your company is working on the next release of a product |> already in the field. An important customer reports a critical bug, |> ... |> | RCS supports this very nicely; you simply create a branch for the bug fix | while development continues on the main path. RCS even provides the "-j" | switch (admittedly a very hard switch to use correctly) to help you merge | that fix back into the main branch later. (You can also use System V's | sdiff program, or Larry Wall's patch program, to achieve similar results). | | I believe you can also do this with SCCS, though I haven't personally | created an SCCS branch while another revision was actually checked out. | -- | Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff Yes, RCS and SCCS can both do this, but it doesn't solve the problem. What happens is that the ongoing work for the next release already has some things changed (enhancements, fixes, whatever). It is often very difficult to make a "quick fix" for a customer in the field once new release work begins without getting unwanted/untested code into it. Once new release work has begun, unless you have a parallel set of code which contains only the currently released product, you need to extract an older revision EVERYTHING that has changed from RCS/SCCS/whatever, not just the module you are making a fix to. For this reason, we maintain separate areas for each release. Yeah, it takes more disk space, and yeah you have to make the fix in more than one place (the release the customer has, and the next release), but it requires a lot less work than extracting back revisions of everything from from SCCS, making the fix, recompiling, and magically merging the fix back into SCCS (and praying that it merged it correctly). -- Tim { Did this posting answer anything, or just make it worse? :-} -- tim@brspyr1.BRS.Com uunet!steinmetz!brspyr1!tim ============================================ Tim "The Enchanter" Northrup
geoff@desint.UUCP (Geoff Kuenning) (02/07/88)
In article <2527@brspyr1.BRS.Com> tim@brspyr1.BRS.Com (Tim Northrup) writes: > For this reason, we maintain separate areas for each release. Yeah, it > takes more disk space, and yeah you have to make the fix in more than > one place (the release the customer has, and the next release), but > it requires a lot less work than extracting back revisions of everything > from from SCCS, making the fix, recompiling, and magically merging the > fix back into SCCS (and praying that it merged it correctly). This is pretty much what I do, except for minor variations due to disk space. Even if you have a single area for both releases, the merge process boils down to making the fix twice, and in either case you can use automated tools (perhaps making a temporary extra copy of an SCCS file) to ease the task if this is appropriate. As to making sure the merge is correct, I do two things. If I can use RCS, it warns me pretty nicely about merge conflicts, leaving extra lines in the code to help the post-edit. And for any source control system, I diff and eyeball the code before checking it in. This works pretty well for small changes; for large ones, you're just stuck with extensive testing. -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
cl@datlog.co.uk (Charles Lambert) (02/09/88)
In article <1664@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: > RCS even provides the "-j" switch to help you merge that fix back into >the main branch later. > >I believe you can also do this with SCCS, though I haven't personally >created an SCCS branch while another revision was actually checked out. Indeed you can: for merging, SCCS provides the -i option to include deltas that are in another branch. That is the basis of the integration and reconcilliation mechanisms in the prototype system I described (see past articles). It's a primitive facility, though, being unavoidably stupid about colliding changes (except where two deltas delete the same line). ------------------ Charles Lambert Data Logic UK Ltd, Harrow, England