From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3c8a1ddc13ecb354 X-Google-Attributes: gid103376,public X-Google-Thread: 114f47,b2be1ebd5e80edf8,start X-Google-Attributes: gid114f47,public From: dweller@dfw.net (David Weller) Subject: Re: Configuration Management for Ada on Unix Date: 1996/05/31 Message-ID: <4oms1i$smh@dfw.dfw.net>#1/1 X-Deja-AN: 157723982 references: <9605301407.AA03821@most> <4olq5p$6nb@f111.iassf.easams.com.au> <4omf1q$jaq@goanna.cs.rmit.EDU.AU> organization: DFWNet -- Public Internet Access newsgroups: comp.lang.ada,comp.software.config-mgmt Date: 1996-05-31T00:00:00+00:00 List-Id: In article <4omf1q$jaq@goanna.cs.rmit.EDU.AU>, Richard A. O'Keefe wrote: >bjw@f111.iassf.easams.com.au (Brendan WALKER) writes: >>The first is that CVS allows more than one user to be modifying a >>file at a time, rather then the SCCS/RCS single file lock system. This >>may sound crazy at first, but it is actually very good. What CVS does is >>automatically "merge" the changes made on a particular version of the >>file. > >A method of merging deltas was described some years ago. >It sounded to me like a really bad idea then, and does now. >The assumption here is that changes that affect different lines are >independent. >I have never known this to be the case. > I felt the same way before I started using CVS. The real issue is how much _control_ you can have over how sources are changed and how versions are tracked. There is already a lot of empirical evidence, covering hundreds of thousands of lines of code (admittedly, most if it in C). The common "fear"(myth) of "merge-based" CM is that you could end up with a change history like this: Module Version 1.1 / \ / \ User A changes User B changes lines 5-10 lines 20-56 \ / \ / Resulting "remerged" file is a mess because the changes from User A "hosed over" User B's changes. This is actually _not_ how the system works. In general, one user (A or B, you choose) will notice the repository has a changed version of the file. The person should inspect the changes (easily done) and determine how/if it affects their changes. No CM system in the world replaces programming discipline. Further, CVS provides mechanisms to force "sequentializing" of checkin.checkout, just like you would get with "vanilla" RCS. Having had several people using CVS on my project, many working with the same packages, I can confirm that the "line oriented" approach (versus "file locking oriented") works wonderfully. More to the point, it is very easy to roll a change out if there are unexpected conflicts (we've never had that situation come up -- CVS will _force_ a user into Merge mode if their changes conflict with any new changes in the repository). The "theory" that "line oriented" CM is error prone holds about as much water as the "theory" that somebody can write more efficient code in C than in Ada because C lets them "get close to the machine" -- it's simply a misplaced "will to believe". >Fifty years of programming language research, and we end up with C++ ??? Fifty years of CM and people still use SCCS :-) -- Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch This is not your father's Ada -- lglwww.epfl.ch/Ada