Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site dicome.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!stolaf!mmm!dicome!salmi From: salmi@dicome.UUCP (salmi) Newsgroups: net.wanted Subject: software control issues Message-ID: <765@dicome.UUCP> Date: Wed, 5-Mar-86 14:56:01 EST Article-I.D.: dicome.765 Posted: Wed Mar 5 14:56:01 1986 Date-Received: Sat, 8-Mar-86 18:45:15 EST Distribution: net Organization: Dicomed Corp, Minneapolis, Mn Lines: 42 hello world! i am asking for opinions/facts about source code control systems. not the type of system that is distributed with unix (rcs,sccs), but a logical approach to controlling many hundreds/thousands of source code modules. the old method that we are finally putting to rest is based on a completely manual system. lots of paperwork produced/shuffled around,. but it seems that no one ever uses the paperwork. it gets archived and left to collect dust. what i am asking for, in essence, is a description of how other software houses control the modification/revision of their code. we have, for example, a single set of source code that may result in 3 or 4 different binary products. we have hashed over the possiblity of seperating the source into 3 or 4 different versions, but we have opposition to that idea from the team working on the project. sooner or later rcs will take charge of all this mess. we would like the transition to be as smooth as possible (to rcs), but need strict guidelines to adhere to a set of rules. if anyone has been in the same type of situation and has somehow 'gotten out from under' the paper mess, i would appreciate hearing from you. this issue is really becoming a headache. as always, thanks in advance... -john salmi -dicomed corporation -minneapolis, mn -ihnp4!dicome!salmi ^^^^^^ ^ | v notice the new, shorter and improved address ;-) -- john salmi {ihnp4,mgnetp}!dicomed!salmi system administrator dicomed corporation minneapolis, mn 612/885-3092