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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin2!goblin.stu.neva.ru!aioe.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: need help learning Ada for a modula-2 programmer Date: Thu, 30 Jan 2014 17:21:10 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1391124070 23604 69.95.181.76 (30 Jan 2014 23:21:10 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 30 Jan 2014 23:21:10 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Original-Bytes: 5910 Xref: number.nntp.dca.giganews.com comp.lang.ada:184616 Date: 2014-01-30T17:21:10-06:00 List-Id: "Dirk Heinrichs" wrote in message news:lce0ob$rid$1@online.de... > Randy Brukardt wrote: > >> I strongly disagree with this advice. The time to write revision history >> entries is when you are either about to write the code or just finished >> doing so (and more rarely, in the middle). That's when all of the >> important issues are fresh in your mind. It's definitely not at check-in >> time, which occurs after all testing is completed. For the Janus/Ada >> compiler, that means after running the entire ACATS and in-house test >> suites (twice, in Ada2007 mode and Ada95 mode). That's at a minumum 4 >> hours later - by which time you're likely to have forgotten half of the >> information that ought to be in the change log. > > Is this really the cycle every developer needs to go through? I'd think > that > in this case the long running tests would be performed at a later stage, > for > example when your current change branch is merged. Change branch? I suppose it depends on your workflow, but I would never waste time with such a thing. I always divide my work is almost always divided into subtasks with an ideal duration of 4 hours or so. I only check in changes at the end of a subtask, after testing (not necessarily full testing, but as much as I can run before I go home). The goal is that the compiler will work the same or better after the completion of a subtask; it shouldn't be the case that it works worse. With such a workflow, there is no need for a change branch, because there almost never will be a need to roll back more than one subtask (that is, to the previous item in the VCS). About the only time I would use a branch is if I was doing an experimental rewrite of some component. In that case, one branch or the other will ultimately be abandoned completely. I would never, ever trust an automated merge of any sort, I've got way too many horror stories with that. >> It's also important to >> have it in the file if the source is likely to be separated from the >> version control at some point -- which is almost envitable in today's >> world (for instance, when the version control in use is changed). > > Which version control is this that you'd change to w/o having proper tools > for migrating _all_ your data (incl. metadata)? What sort of VCS would have "proper tools" for mitigrating from an arbitrary other VCS? I can't imagine such a thing. Maybe there would be a tool for mitigrating from some really popular VCS, but that almost guarantees that it would be bad. :-) I'm never met a VCS which understands that the relationship between versions of files is a graph, not a tree, and that tools for maintaining multiple versions of a program, using various combinations of versions of files, is what real programmers often have to do. I built a homebrew system to sit on top of a VCS to provide and manage those relationships, and I can't imagine how anyone could have "tools" to migrate that information when they don't even understand the basic problem. (The only use I have for a VCS is to manage the differences; nobody does relationships usefully.) I spent a month writing way to convert the VCS files from PVCS to CVS back in the day, and I wouldn't wish that on anyone. >> IMHO, if your depending on merges, especially automated merges, to keep >> your version control consistent, you're already in trouble. You're >> probably losing a percentage of your team's work every day. > > I don't get that one. An automated merge always has to guess what's new and what's old, and everytime it gets it wrong, you will lose some changes. Now, I suppose if you have a formal change branch and if there is only one change involved, then the merge will be flawless. But that's true because there shouldn't have ever been a branch in the first place. So the "merge" in question is essentially the same as my normal check-in. The problem comes if multiple people modify the source at the same time. In that case, an automated merge is just an accident waiting to happen - it just *appears* to be safer than the complete loss of whomever checks in last. I'm of the opinion that only a file's owner should be allowed to check in changes to it. Other people need to send the owner changes which they merge manually. (Preferably, the work is distributed by Ada packages so that there is no need for this.) I suppose one could use a change branch for this (non-owner changes) -- in order to avoid having to have a second way to communicate source code, but that's primarily a convinience; such a branch would be dead after the manual merge and nothing of it would remain in the main VCS logs. Randy.