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: <39047DE1.A8E13A11@Raytheon.com>#1/1 X-Deja-AN: 615043463 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> <8dke9a$hc1$1@nnrp1.deja.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: > > In article <874s8yeg81.fsf@deneb.cygnus.argh.org>, > Florian Weimer wrote: > > Ted Dennison writes: > > > > > No warnings are given, no backups are made. The old version is > > > over-written. Even for those who know the danger, this would be easy > to > > > accidentally do. > > > > This can't happen with systems like CVS where each user works on his > > private copy of the source files. The master files are often not > > directly accessible. Problem solved. ;) > > Hmm. I use CVS at home, but I guess that's not multiuser (yet, perhaps > It'll be that way when my kids are older :-) ). > > I'm still not convinced CVS wouldn't have the problem too. But at least > the process give you one hint. I see it working this way. > > User A does a "cvs checkout" of the repository > User B does a "cvs checkout" of the repository Here is your problem. Any tool which does not provide some check on multiple check-outs and a way to prevent then is seriously broken IMO. Access controls become more and more important as project size grows, or the separation between developers increases. Multiple changes to the same source simply cannot be allowed. Merging is just not a viable mitigator to this chaotic sequence of events. > User A starts up emacs (which reads the exception file into memory). > User B starts up emacs (which reads the exception file into memory). > User A hits Ctrl-C Ctrl-Y > User A does a "cvs commit" on the exception file > User B finds out there were changes, and does a "cvs update" > User B hits Ctrl-C Ctrl-Y (unknowingly wiping out user A's changes) With access controls, this would not happen because the B's check-out would have failed. This mentality of letting anyone do anything and merge it all together later is simply frought with too many pitfalls. > User B does a "cvs commit" > > At least this way, there is a manual updating step in there, where the > wise user could say, "I'd better bring my emacs up to date, just to be > safe." But it'd still be awfully easy to forget, or overlook a running > session somewhere. There in lies the rub. Merging later depends upon that later actually coming. Better to prevent multiple changes up front. User A and B have a file based upon some common version. User A checks it out, makes changes, and then checks it in. User B checks it out and fails because he does not have the latest version. User B can not attempt the check out again and force the system to ignore User A's changes (B had better know what he is doing here) or User B can accept the changes from User A and then check out the file. > > -- > T.E.D. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!"