friedl@vsi.UUCP (Stephen J. Friedl) (06/03/88)
Hi wiz.kind.of.people,
I need to implement a configuration management system on a
couple of customer projects. While I know of some high-end
systems in development (one really cool one at AT&T), these are
overkill in the short term. Basically, I cannot imagine that
anybody out there uses SCCS without some front-ends to manipulate
s-lists and such; would anybody care to share some of this wisdom
with me? I don't so much need the code -- I can handle that part
-- I just need some ideas on what will make a safe, nonintrusive
version-control system. I realize that "safe" and "not getting
in the way" are often mutually exclusive, but anybody else could
do better than what I have now. Manual pages, docs, code, ideas,
whatever. I've wanted this for two years and am finally going to
do it. Please help...
Steve
--
Steve Friedl V-Systems, Inc. (714) 545-6442 3B2-kind-of-guy
friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
Nancy Reagan on ptr args with a prototype in scope: "Just say NULL"beres@cadnetix.COM (Tim Beres) (06/04/88)
In article <698@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: > I need to implement a configuration management system on a >couple of customer projects. While I know of some high-end >systems in development (one really cool one at AT&T), these are >overkill in the short term. Basically, I cannot imagine that >anybody out there uses SCCS without some front-ends to manipulate... Probably not the answer you wan't, but...I designed just such a front end about 2 years ago. First the specifics, then a recommendation: * Front-end to the myriad of commands and options, written in C. This did extensive permission checks to allow our users (BTW, this was at a different Co.) to look at, but not modify source, unless they were *The SCCS Administrator*. Some of the specifics escape me, but if you want a secure front end, you have to setuid it to this account, with some additional checks in the front-end. Note: there is some documentation around that describes how to make an SCCS front end security conscious. I believe it came with the AT&T Un*x SysV docs. * Since all that the front end did was to enhance security provisions I implemented a Bourne Shell user interface to talk to the front end. This piece was the only nice and elegant part of the system. With shell functions and such, it hid all of SCCS's ugliness from the admin (me - how's that for seperation of powers?). Recommendation: * Forget SCCS. Use RCS or bite the bullet and use the "cool AT&T" or Sun's NSE. SCCS is horrid to use and doesn't do things that RCS, say, does. Worst of all, the things you put into your front end can modify *the CM system* you are creating. You must then port, fix and track your front end(s). Why not let someone else do that dirty work, and you can busy yourself with the procedures necessary for your customers to actually use the system. If anyone needs more detail on the front end I did, forget it. The info is probably proprietary^. I don't have the specs or code and it ain't worth it to you anyway. ^ - My former employer, Tech-Source/Tech-Source Labs/Tech-Source a Div. of Ciprico/FCG Engineering/Florida Computer Graphics (same place and people - many guises), may or may not be around. Rhetorical question: if your former employer bites the dust, what about all the agreements you signed? -Tim [[I would disclaim this, but unfortunately I had to sign a non-disclaimer agreement]] Tim Beres Cadnetix, 5775 Flatirons Pkwy, Boulder, CO 80301 beres@cadnetix.com {uunet,boulder,nbires}!cadnetix!beres