Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!xadmx!mark@spider.co.uk From: mark@spider.co.uk (Mark Valentine) Newsgroups: comp.unix.questions Subject: Re: Source Code Control Message-ID: <19934@adm.BRL.MIL> Date: 8 Jun 89 11:47:04 GMT Sender: news@adm.BRL.MIL Lines: 70 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/\ My company wouldn't dare associate themselves with my opinions.