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: border2.nntp.ams2.giganews.com!backlog4.nntp.ams3.giganews.com!backlog4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.mixmin.net!newsfeed.tele2net.at!newsfeed.utanet.at!texta.sil.at!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!feed.news.schlund.de!schlund.de!news.online.de!not-for-mail From: Dirk Heinrichs Newsgroups: comp.lang.ada Subject: Re: need help learning Ada for a modula-2 programmer Date: Thu, 30 Jan 2014 18:05:15 +0100 Organization: Privat Message-ID: References: NNTP-Posting-Host: pd9ff84b5.dip0.t-ipconnect.de Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Trace: online.de 1391101515 28237 217.255.132.181 (30 Jan 2014 17:05:15 GMT) X-Complaints-To: abuse@einsundeins.com NNTP-Posting-Date: Thu, 30 Jan 2014 17:05:15 +0000 (UTC) User-Agent: KNode/4.12.1 X-Original-Bytes: 2660 Xref: number.nntp.dca.giganews.com comp.lang.ada:184610 Date: 2014-01-30T18:05:15+01:00 List-Id: 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. > 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)? > 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. Bye... Dirk -- Dirk Heinrichs Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de