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,791530e499e6a7f9
X-Google-Attributes: gid103376,public
From: Robert A Duff <bobduff@world.std.com>
Subject: Re: ada writing guide
Date: 2000/04/24
Message-ID: <wccem7v8jt0.fsf@world.std.com>#1/1
X-Deja-AN: 615059352
Sender: bobduff@world.std.com (Robert A Duff)
References: <8d1rso$bir$2@bunyip.cc.uq.edu.au> <8d1vhj$hdr$1@nnrp1.deja.com>
 <8d2hig$7e6$1@nnrp1.deja.com> <38F5DF8C.1A01E5A4@utech.net>
 <8d4t07$o15$1@nnrp1.deja.com> <38F603FE.B0C3ED83@utech.net>
 <8d5dsc$c27$1@nnrp1.deja.com> <8d6hjn$j9p$1@clnews.edf.fr>
 <8d76vj$9jt$1@nnrp1.deja.com> <8d7uak$1d1$1@wanadoo.fr>
 <8dfd6q$uch$1@nnrp1.deja.com> <87em84vavt.fsf@deneb.cygnus.argh.org>
 <8dfpj7$crs$1@nnrp1.deja.com> <38FF1D6B.4120AF7B@Raytheon.com>
 <38FF4D28.8F946BDA@telepath.com> <3904808C.BC4AD31A@Raytheon.com>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 2000-04-24T00:00:00+00:00
List-Id: <comp.lang.ada>

"Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes:

> I only like to add that I now understand the actual nature
> of your problem.

I'm glad you posted this.  After seeing your previous posting, along
with many others incorrectly blaming sloppy CM, I was about to start
ranting and raving about "why doesn't anybody get it?!"  ;-)

The point is that this was a bug in Emacs, and no CM system could
possibly prevent the problem.  Actually, not a bug in Emacs per se, but
a bug in an Emacs extension.

In particular, Emacs was overwriting a (properly CM'ed) file with bogus
information it (Emacs) had evilly saved in its own in-memory buffers.
No CM system could prevent that -- it doesn't matter whether you like
the strict-locking style, or the "hack now, merge later" style.  Neither
one could prevent Emacs from overwriting the (properly checked out!)
file with bogus obsolete data.

>... I can't say why I didn't get it before but
> it was Emmanuel Briot's post which finally clued me into
> to the real problem you were talking about.
> 
> Integration of CM tools with other tools is a black art.
> You have an integration problem which no CM tool can
> fully prevent.

No, I don't agree.  The blame clearly lies on the Emacs side, not on the
CM side.  And (apparently) the bug has been fixed, which indicates that
the author of the Emacs extension in question agrees.  Let's not be
wishy-washy, and blame the bug on some amorphous interface between the
two.

>... Part of our tool selection criteria is how
> candidate tools can be fit into our CM system. Some tools
> are great at what they do, but their file structures or
> change flows simply make them incompatible with our systems.

True, but this case is a plain-and-simple bug in Emacs (or actually an
extension thereof).

- Bob