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: "Samuel T. Harris" Subject: Re: ada writing guide Date: 2000/04/24 Message-ID: <3904808C.BC4AD31A@Raytheon.com>#1/1 X-Deja-AN: 615047126 Content-Transfer-Encoding: 7bit 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> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Raytheon Aerospace Engineering Services Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-04-24T00:00:00+00:00 List-Id: Ted Dennison wrote: > > "Samuel T. Harris" wrote: > > > Any version control system which allows Fred to simply check-out > > the file without warning him that his content is no longer > > based on the latest version is seriously broken! This is a > > basic access control feature. If you want this protection, > > then support of this feature becames a primary tool selection > > requirement! > > (Sigh). You are talking about a different revision control setup than I was > in the quoted post (one in which the latest source is always visible, unless > a local copy is checked out for editing). I addressed the (CVS) style you are > referring to in another post. Suffice to say, the problem still exists in the > setup you are talking about too (unless you have some kind of revision > control system that notices that emacs has an obsolete copy loaded in its > internal buffer). > > It seems like a lot of heat is getting generated on this issue due to > misunderstandings about how different revision control systems work. The > tragic part of this is that it doesn't matter at all what style of RCS you > are using. We are *not* talking about external files here, but a buffer > internal to emacs that never again gets checked against the file it was > loaded from. No gyration done with external files can *possibly* solve this > problem. > > Clearly the right solution to this problem (emacs checking the file for > changes before writing it back out), has already been arrived at and > implemented. So I don't see much point in continuing to sit here and argue > over whether the problem exists. If the maintainer of the emacs ada mode saw > that it exsits, and thought it was enough of a problem that it warranted > fixing by the next revision, that's good enough for me. > > If anyone still feels compelled to continue this discussion, please at least > do me the service of writing down your own scenario that shows how this won't > be a problem. I feel like I'm swinging at the wind here. > I only like to add that I now understand the actual nature of your problem. 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. 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. I have felt your pain! -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!"