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!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: need help learning Ada for a modula-2 programmer Date: Thu, 30 Jan 2014 12:13:02 +0000 Organization: A noiseless patient Spider Message-ID: References: <2116015800412726948.362542rm-host.bauhaus-maps.arcor.de@news.arcor.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx05.eternal-september.org; posting-host="f4c34a0d1a0b50d7528d4047756bbea8"; logging-data="26374"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/UNyxga5LZdUxMYuMWLxsyozdtGJEKt9k=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin) Cancel-Lock: sha1:ZtOZ9jVJtvT3Fdi1wcT4eQl+4Wg= sha1:wD3y0y9J0nubSX7gNzNoarMjaLY= X-Original-Bytes: 2923 Xref: number.nntp.dca.giganews.com comp.lang.ada:184604 Date: 2014-01-30T12:13:02+00:00 List-Id: Georg Bauhaus writes: > "Randy Brukardt" wrote: >> "Dirk Heinrichs" wrote in message > >>> >>> You should avoid putting the revision history _into_ your >>> files. It's the job of your version control system to handle >>> this. Putting it into the file increases the probability of getting >>> merge conflicts. >> >> 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. > > Depending on the VC system, and on the note taking features of the > IDE, the two approaches can be combined. One branch is for frequent > commits of things just finished, and another branch is for whole > change sets (after testing). The description of the whole change sets > can then draw upon notes that were written earlier, when adding to the > frequent commits branch. I don't use git, but AIUI 'rebasing' supports frequent commits with the ability to elide them later so you only see the overall effect. What happens to the change log I don't know. Mercurial has queues[1] which allow you to build up a patch over time, updating the overall commit message as you go. Personally I don't find it hard to remember what the changes were over a reasonably short period, but then it's easy to do one thing at a time on personal projects. Of course, that's not the same as remembering what the changes were _for_, but I'm not sure that the RCS is the right place for that anyway? [1] http://mercurial.selenic.com/wiki/MqTutorial