Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@crhc.uiuc.edu (Andy Glew) Newsgroups: comp.unix.questions Subject: Re: Read only Source trees? Message-ID: Date: 12 Sep 90 01:04:18 GMT References: Sender: news@ux1.cso.uiuc.edu (News) Organization: Center for Reliable and High-Performance Computing University of Illinois at Urbana Champaign Lines: 41 In-Reply-To: bglenden@mandrill.cv.nrao.edu's message of 11 Sep 90 19:51:46 GMT If you don't want to be able to prepare all the binaries simultaneously, use SCCS or RCS and version names, with a different name (or set of names) for each different binary version. In general, version names can be divided into two classes: historical names, which once put in place never change, and current names, like 'Latest-Greatest-Version-For-Foo', which change every time an update or bugfix is made. If you want to be able to prepare all the binaries simultaneously, try using link farms - whether symlinks or hardlinks depends on your situation. Create a single, central, RCS tree. Create several "views" of the source tree, containing the current source for a particular version. Share files common to more than one view using links. Let every developer have her own view. In the paper "Boxes, Links, and Parallel Trees: Elements of a Configuration Management System", USENIX Workshop Proceedings, Software Management. USENIX Association, April 3-4, 1989, New Orleans, Louisiana, I describe such a CM system I devised for UNIX system development at Gould. IMHO it was pretty good - developers who got used to it recreated it on their own when we moved from BSD to System V. As I recall at the workshop, half of the audience thought it was a really neat idea, and the other half though it was all old hat. "Doesn't everybody do things that way". It featured, in particular, RCS wrappers to move between several overlaid RCS trees, hardlink cloning (saved space and permitted chroot), and chroot "boxes" to totally isolate one developer from another developers changes which might happen to get installed on the development system by accident... (reducing problems like "I didn't think my compiler bugfix would cause you to spend a week chasing down a bug in the OS"...) There are a number of commercial systems out there, but rolling your own (1) isn't hard, and (2) gets you more features than most commercial systems I've seen. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]