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: Ted Dennison Subject: Re: ada writing guide Date: 2000/04/20 Message-ID: <38FF57B2.C2A41554@telepath.com>#1/1 X-Deja-AN: 613696740 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> <8dgk8i$ak4$1@nnrp1.deja.com> <8dhqi7$jv3$1@nnrp1.deja.com> <8dhuuu$ou5$1@nnrp1.deja.com> <8di8da$4el$1@nnrp1.deja.com> <874s8yeg81.fsf@deneb.cygnus.argh.org> <8dlcv0$lbt$1@nnrp1.deja.com> <38FF12A1.3551DE9F@telepath.com> <8766tcwzln.fsf@deneb.cygnus.argh.org> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: Abuse Role , We Care X-Trace: newshog.newsread.com 956257917 216.14.8.65 (Thu, 20 Apr 2000 15:11:57 EDT) Organization: Telepath Systems (telepath.com) MIME-Version: 1.0 NNTP-Posting-Date: Thu, 20 Apr 2000 15:11:57 EDT Newsgroups: comp.lang.ada Date: 2000-04-20T00:00:00+00:00 List-Id: Florian Weimer wrote: > Ted Dennison writes: > > > I have already explained that this scenario can occur just as easily > > when the revision control master files are not directly accessable. > > No, you have shown that careless programmers can make a mess even if a > CM system is used. For example, with CVS, a programmer cannot commit > his changes to a file if they are based on an outdated version (i.e. a > newer one has been committed to the repository since he first checked > out the file). He has to adapt his changes to match the newest > version of the file first. Of course, if the programmer doesn't Since I don't see any specifics in my post addressed, I'll try to do it for you myself. One of us is missing something. It could well have been me: 1. User does checkout of cvs repostitory 2. User starts emacs, which loads the exception file into a local buffer. 3. Exception file changes outside of emacs, and is updated. 4. User realizes that lots of stuff is out of date (not nessecarily just exception file), so he does a "cvs update". Now as far as CVS is concerned, user is looking at the most up-to date version. However, his emacs is still working from the old exception file. 5. User sees a new exception, and does a Ctrl-C Ctrl-Y, which saves the *old* version of the exception file to disk, with his one update 6. User wants his new exception saved in cvs, so he does a "cvs commit". Cvs has no problem with this, as it thinks the user was working from the latest version. Now the result of this process is that User just wiped out the previous version revision-controlled changes to the exception file. So what are your *specific* problems with this scenario? You said: * "Careless programmers can make a mess, even if CM is used". So perhaps you think that User above was being careless in not routinely doing an update of emacs' internal exceptions buffer before doing the write? That is perhaps a reasonable position. But in that case, why bring up revision control at all? Revision control doesn't even materially change the mistake a "careless" programmer has to make. It just adds some steps to either side of it. Plus, if the way to *not* be careless is to take one extra step (reloading the exceptions buffer) every time it is saved, what's wrong with advocating that emacs do both instead of just the one? Why leave it open to easy carelessnes? Why make the user perform two steps (forgetting one of which will sliently hose his file) every single time? * "with CVS, a programmer cannot commit his changes to a file if they are based on an outdated version". This is true only in the abstract. All CVS does is force the programmer to have issued a "cvs update" from the most recent version before he does a "commit". CVS does not force emacs to reload its local copy of that file. Emacs, won't notice the problem on its side, like it would for a normal file. CVS has no way of telling that the file used for "commit" really was based off that "update" file. If emacs wipes out that most recent version with something based off an older version, CVS can't help you. -- T.E.D. Home - mailto:dennison@telepath.com Work - mailto:dennison@ssd.fsi.com WWW - http://www.telepath.com/dennison/Ted/TED.html ICQ - 10545591