john@tirnan.UUCP (John Richartz) (05/31/89)
I'd like to second MacK's motion for a discussion of source code
control strategies, facilities, or systems. I'm involved in
implementing a source code control capability and have chosen to
base the implementation on CCC from Softool (after considering
extending SCCS, or using ADC from SMDC) and am not having very much
luck finding realistic discussions of usable facilities. We're
developing this in an environment of networked multiuser machines
on which one will act as a source code repository with development
occurring on the others.
Clearly, the floppy (I guess this is a reference to PC based
development) approach, or anything similar, is fraught with peril.
But any approach based on ad-hoc procedures is likely to produce a
product that is difficult or impossible to maintain - particularly
when multiple product versions, products requiring site or
installation specific differences, or derivative products must be
managed. While I'm reluctant to admit such a thing, even a PC can
be used as a legitimate platform for some aspects of the
development and provision must be made within a 'real'
configuration control (note the change from "source control")
system to accomodate this.
I'm taking the approach that the 'developers' are responsible for
provision of the source code and for changes to handle bug fixes
and functional product extensions, while the configuration
management people handle release builds, packaging, and releasing
the product. (Developers are responsible for builds during their
unit test activity, but use the same build procedures as
employed for release builds.)
Another consideration is to connect the configuration management
system to the problem tracking system to allow us to readily
track the progress of bug fixes through the resolution stage.
This, of course, requires some discipline in generating change
documentation - both to initiate a change to a product, and by
the developer to identify what he did (or intended to do when
operating on a source module).
So, how 'bout it, guys? Like to discuss capabilities provided to
developers? source control environments? configuration
management issues??? In another newsgroup, perhaps?
John Richartz
!tektronix!reed!tirnan!johnrunyan@hpirs.HP.COM (Mark Runyan) (06/02/89)
>/ john@tirnan.UUCP (John Richartz) / 10:08 pm May 30, 1989 / > > I'd like to second MacK's motion for a discussion of source code > control strategies, facilities, or systems. ... >... > So, how 'bout it, guys? Like to discuss capabilities provided to > developers? source control environments? configuration > management issues??? In another newsgroup, perhaps? Which newsgroup should it be in? I'm interested.
mark@spider.co.uk (Mark Valentine) (06/08/89)
From: john@tirnan.uucp (John Richartz)
Date: Fri 2 Jun, 1989
Subject: Source Code Control
[...]
So, how 'bout it, guys? Like to discuss capabilities provided to
developers? source control environments? configuration
management issues??? In another newsgroup, perhaps?
I think the time is right to make a concerted effort at least to discover
what the real state of affairs is out in the big wide world. I would be
pretty confident at guessing there are large numbers of development groups
still struggling along with make and sccs, or with quickly cobbled together
systems that they've knocked up themselves to get round the worst of the
problems. At least I don't think *we* are unique!
>From what's been visible to me as a (fairly typical?) developer trying to
keep an ear close to the ground, it seems that at least some of the semi-
academic groups (in Europe especially) have been trying to come up with
solutions which tackle medium-sized projects, but it's still the case that
the commercially available systems are huge monsters which still don't cater
much for the possibility of creating a source release that will build in a
standard Unix environment (divorced from the system from which it was spawned)
and still be flexible enough to be hacked on outside the system. That's what
our customers *need* as an end product.
I for one am all set to play with stuff like ``shape'' that's now appearing
in comp.sources.unix (and see also ``cake'' and ``cvs'' from a while back),
because I think with a little effort these tools are going to satisfy my needs
better than most of the commercial products. How do others feel about issues
such as the difference between shipping your product build tools with your
product versus having your configuration management produce a set of standard
makefiles? I tend to favour the latter, since often most of the complicated
stuff is done by the time you actually want to build a system, and there are
some strange targets on which you would otherwise have to support your build
tool. However, another approach is to use an intermediate tool such as
``imake'' which is small enough to support and gets around some of the hassles
of raw make. The production of standard (semi-portable) makefiles/imakefiles
is not something I have seen tackled at great length.
There are lots of issues to discuss, and I'm sure there are significant
numbers of folks thinking about them privately! Let's apply some communal
effort and speak to each other and to the people who are implementing these
tools. Too often I think that commercial development groups have kept their
problems to themselves, solved them partly to suit their own requirements, and
sold the result at a price which is just too much for other groups to fork out
for a system that doesn't quite match their own way of working and can't be
made to do so because it's become a proprietary system. There now appear to
be a number of groups willing to produce more general and open solutions, and
I'm sure that they would appreciate input from real-life commercial groups who
don't have the resources to go it alone. What's more, I'm sure they'd appre-
ciate the funding that we could undoubtedly provide if we knew the work was
going to benefit us in the foreseeable future! Am I being too naive and/or
radical??
Let's hope I've poked at something relevant here, and let's have a show of
hands from those who think we *should* be discussing this sort of thing.
I don't think this forum is entirely inappropriate. It has the advantage
of widespread distribution via a mail gateway (which is how I imagine lots
of folk in smallish companies like mine without newsfeeds read it).
Say something?
Mark.
__
Mark Valentine, Spider Systems Limited, Edinburgh, UK. /\oo/\
<mark@spider.co.uk, mark%spider.co.uk@uunet.uu.net, uunet!mcvax!ukc!spider!mark>
My company wouldn't dare associate themselves with my opinions.john@tirnan.UUCP (John Richartz) (06/10/89)
Thanks to Mark Runyan (runyan@hpirs.HP.COM) and Mark Valentine
(mark@spider.co.uk) for responding to my suggestion for discussion
of these issues.
It strikes me that comp.software-eng might be an appropriate place
for discussion, since it seems to be fairly low volume now, and
they're currently pretty hung up on whether software engineering
really exists and whether you're better off training an Engineer
to develop software than to teach a Software guy engineering.
Mr. Valentine does, I believe, characterize the situation fairly
well. I've worked with several (mostly ad-hoc) variants of
development based on either SCCS or RCS and find that the structure
is generally not in place to provide a development model that
allows for realistic development of a Product and any variants and
descendents of it (admittedly this often results from lack of
organizational focus on the problems). I believe that this is due
to an inherent weakness in the model of a product as the state of a
particular set of source files, rather than as the collection of
source files and configuration specifics that define a particular
instance of the product.
"Source Control" is only a part of the problem and one can feel
fairly comfortable knowing that the developers have retained a file
revision history for each file, and one can certainly snapshot the
development at product release by treating the product as the list
of files in the source control system at some revision (the
software bill of materials kind of approach, useful with both SCCS
and RCS). But this gets really messy when you've got either
multiple similar products, or perhaps site specific versions. So we
immediately find ourselves considering a higher level abstraction of
the product - and ending up with "Configuration Control/Management"
rather than just source archiving.
So - comp.software-eng?
john richartz
!tektronix.tek.com!reed!tirnan!johnpgh@stl.stc.co.uk (Peter Hamer) (06/13/89)
In article <133@tirnan.UUCP> john@tirnan.UUCP (John Richartz) writes: > > I've worked with several (mostly ad-hoc) variants of > development based on either SCCS or RCS and find that the structure > is generally not in place to provide a development model that > allows for realistic development of a Product and any variants and > descendents of it ... > > "Source Control" is only a part of the problem ... I know the problem well! A configuration management system called Shape has just been distributed on comp.sources.unix. You will probably find the papers included in the distribution well worth the effort of unpacking all 33 parts; they are very interesting. Shape is in some ways yet another SCCS/RCS combined with yet another Make. However, it is built on an 'Attribute FileSystem' which maintains a distinction between objects and their attributes. This enables Make requests of the form 'select the newest version of all components I am working on and the newest published version of all other components' to be used. Similarly, some of the problems of variants seem to be addressed; both when the variants are realised as separate sources, and when they are realised as a common source with different compiler-time flags. I would be interested in other peoples comments on the approach adopted by the Shape team, and any feedback from people using it [or trying to use it]. Please read the Shape papers and don't rely on the accuracy of my summary.
johnm@uts.amdahl.com (John Murray) (06/14/89)
In article <133@tirnan.UUCP>, john@tirnan.UUCP (John Richartz) writes: > > [... Having used] either SCCS or RCS[, I] find that the structure > is generally not in place to provide a development model that > allows for realistic development of a Product and any variants and > descendents of it (admittedly this often results from lack of > organizational focus on the problems). . . . > [...Things get] really messy when you've got either > multiple similar products, or perhaps site specific versions. A development group frequently suffers from tunnel vision, to the extent that it cannot see how it fits into the entire organization. This seems to be a real problem where both hardware and software are being developed simultaneously, or more particularly, when existing software is being modified to run with new hardware. I like to think of this activity as software "maintenance" rather than "new design". However, organizations prefer to act as if they were designing from scratch, even though they subsequently find themselves porting software fixes forward from earlier versions, and so on. Here's an interesting logistics problem. The prototype hardware has a bug which will take several weeks to fix. A temporary fix is applied to software to get around the problem and allow alpha testing to continue. Software development is still continuing at the same time. When the hardware problem is resolved, how do you back off the temporary fix in an orderly fashion? (This is basically an instance of the site-specific problem, I suppose). Even establishing an appropriate mechanism for tracking the changes can be a paperwork nightmare. At Amdahl, one system we use tracks problem fixes and new s/w enhancements simultaneously, and no source changes are allowed without a corresponding entry in the tracking database. (See Software Engineering Notes, ACM, Oct 1988 for my paper on it.) Merging such software control with the corresponding hardware change control system seems difficult, however; I'd be very interested in hearing opinions on this subject. - John Murray, Amdahl Corp, Sunnyvale, Ca. (My own opinions, etc.)