Source Code Control

[Mark Valentine]

    From: john at 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 at spider.co.uk, mark%spider.co.uk at uunet.uu.net, uunet!mcvax!ukc!spider!mark>
My company wouldn't dare associate themselves with my opinions.