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 X-Google-Attributes: gid114f47,public From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) Subject: Re: Configuration Management for Ada on Unix Date: 1996/05/31 Message-ID: <4onb8p$a18@mulga.cs.mu.OZ.AU>#1/1 X-Deja-AN: 157765460 references: <9605301407.AA03821@most> <4olq5p$6nb@f111.iassf.easams.com.au> <4omf1q$jaq@goanna.cs.rmit.EDU.AU> <4oms1i$smh@dfw.dfw.net> organization: Comp Sci, University of Melbourne newsgroups: comp.lang.ada,comp.software.config-mgmt Date: 1996-05-31T00:00:00+00:00 List-Id: dweller@dfw.net (David Weller) writes: >Richard A. O'Keefe wrote: >>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. The assumption necessary is not that strong. The assumption used by CVS it is that if you have a group of changes which are semantically related to each other, and another group of changes which are semantically related to each other, and none of the changes in the first group changes any of the lines near lines changed by the second group of changes, (where "near" means within a distance of about two lines), then it is probably safe to merge these two groups of changes based on the assumption that they are independant, subject of course to revision by the programmer if the changes turn out to not be independent. >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). Well, I'll add my 2c worth. My experience with CVS in developing a 100,000 line system over two and a half years has been extremely positive. This system was developed by a team initially comprising three core developers, but other the two and a half years eleven people have been involved in adding or modifying code. To be honest, I can hardly imagine how we would have coped without CVS. The main language we used was not C, it was Mercury, a logic/functional language which shares some of the philosophy of Ada -- in particular it has strong static checking. (The system in question was in fact the Mercury compiler, which is written in Mercury.) >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. Right. Neither does any programming language. However, languages with strong static checking such as Mercury and Ada will ensure that even when the above scenario *does* occur, the resulting inconsistency is usually caught by the compiler. In all my experience over the past two and a half years of using CVS on a daily basis, as far as I can recall we have not had a single bug caused by this sort of scenario. -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.