Re: Configuration Management for Ada on Unix

[fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)]

dweller@dfw.net (David Weller) writes:

>Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> 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 <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.