Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!motcsd!hpda!hpcupt1!hpirs!runyan
From: runyan@hpirs.HP.COM (Mark Runyan)
Newsgroups: comp.software-eng
Subject: Re: Re: Source Code Control
Message-ID: <9630001@hpirs.HP.COM>
Date: 16 Jun 89 14:35:12 GMT
References: <133@tirnan.UUCP>
Organization: HP GSY/USO/UKL Cupertino, CA, USA
Lines: 47

>/ hpirs:comp.software-eng / render@m.cs.uiuc.edu /  6:00 pm  Jun 12, 1989 /
>As you mention, SCCS and RCS fall short when you need to do SCM for larger
>projects.  There are several recent systems which attempt to address this 
>problem.  You might wish to take a look at the proceedings from last year's 
>IEEE workshop on software version control for examples.  Also take a look 
>at the last proceedings of the SIGSOFT/SIGPLAN Symposium on Practical Software
>Development Environments.  They talk about 3 or 4 systems (Shape is among them)
>which do some of the things you seem to want.  For more background, there
>was a bibliography on the subject in SIGSOFT Software Engineering Notes 11:3
>(July 1986).  It's pretty complete up to the time it was published and lists
>76 articles.

While I haven't completed reading the references you gave, I have noted one
major issue it what you are pointing out.  There may exist several SCM
systems out there in the market place, but getting them "in house" is not
a simple process.  I'm familiar with several systems that "almost" do
what we need here in our lab, but they all have some shortcoming that makes
it difficult to convince management to purchase the systems.

As an example, what I've read so far on SHAPE indicates that it is a good
replacement for make and RCS, which makes it sound like we could easily
replace our ad hoc system with SHAPE.  However, in my scanning of the
information, I've yet to encounter any reference on how SHAPE works
with networks.  If my development is spread out on several machines, can
SHAPE "transparently" access the source for me, or am I still going to
need the ad hoc support procedures to manage network access?   This doesn't
seem like a major problem to most people, but it will be a stumbling
block to selling management on spending the development time to replace
our tools with a tool set that doesn't do "everything".

As another example, I'll pick on an Un-named Product X (UPX).  This system
appeared to do everything, but it had a basic design assumption that would
make it impossible for us to accept.  Most SCM systems assume there is
one major line of development with the occasional "branch" or divergent
development.  Performance usually suffers if you are on one of these
divergent developments.  However, in a research lab, there is almost always
divergent development going on.  The next two or three releases or new
hardware.  These "branches" sometimes fade into nothing when the project
is proven to be unnecessary, but they must not suffer from poor performance.

What I'm trying to say is, there are several tools in existance, but using
them almost always requires that you adopt the work style required by the
tools and this work style is most probably different than your current one.
This requires changing the work habits of several engineers, some of which
may still not understand the need for SCM.

Mark Runyan