Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!crackers!jjmhome!smds!rh
From: rh@smds.UUCP (Richard Harter)
Newsgroups: comp.sources.wanted
Subject: Re: Multi-User Source Code Managers ?
Summary: Orthogonal and non-orthogonal changes
Keywords: Source Code manager SCCS RCS
Message-ID: <122@smds.UUCP>
Date: 19 Jul 90 03:18:46 GMT
References: <1990Jul17.161924.8248@cid.aes.doe.CA> <7858@jarthur.Claremont.EDU>
Distribution: na
Organization: SMDS Inc., Concord, MA
Lines: 45

In article <7858@jarthur.Claremont.EDU>, ssdken@watson.Claremont.EDU (Ken Nelson) writes:
> In article <1990Jul17.161924.8248@cid.aes.doe.CA>,
> aspgpas@cid.aes.doe.CA (Peter Silva) writes:
> |> I'm looking for a portable source code manager that lets multiple users
> |> modify the same file at the same time.  Two+ users should be
> |> able to get the same mod file (via command like SCCS "get"),
> |> make changes, and only know that someone else was working on 
> |> the same file if the two happen to modify the same LINES of code.

>     Are you sure you want to do this?  Doesn't one line of
>     code affect the behavior of another?  When I make
>     changes, I make them based on assumptions about the
>     behavior of other lines of code in the module/program.
>     If somebody else is making changes to that behavior,
>     watch out.

It depends very much on the nature of the changes, the nature of the
code (and its language), and whether there is a single line of development
or multiple lines.

Within a single line of development you really always want to know if
there are other people working on the same file.  Parallel change is
*relatively* safe if (a) the changes being developed are well defined,
(b) they are independent in function and impact, and (c) the code being
modified is not tightly coupled.  In short, you need well structured code
and a good disciple of change control.

A factor which is frequently overlooked is that changes are made to programs
or software systems -- files are simply one of the ways that software is
modularized.  Changes in separate files, developed in parallel, can interact
with each other if the coupling between them is affected.

As a general rule parallel development of changes works best if the code
is highly modular, coupling is disciplined, and there is a strong discipline
of change control in which changes themselves are modular with a minimum
of coupling.

It is also *very* important that merged changes be rigorously tested!
No formal mechanism of merging can guarantee that the merged code is
correct.
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.