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!backlog3.nntp.ams3.giganews.com!backlog3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
User-Agent: NewsTap/3.5.5 (iPad)
From: Georg Bauhaus <rm-host.bauhaus@maps.arcor.de>
Newsgroups: comp.lang.ada
Content-Type: text/plain; charset=UTF-8
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: 
 <2116015800412726948.362542rm-host.bauhaus-maps.arcor.de@news.arcor.de>
Subject: Re: need help learning Ada for a modula-2 programmer
References: <lcbc0j$cci$1@online.de> <lcbp66$8gr$1@loke.gir.dk>
Date: 29 Jan 2014 22:53:35 GMT
Organization: Arcor
NNTP-Posting-Date: 29 Jan 2014 23:53:35 CET
NNTP-Posting-Host: bb009588.newsspool4.arcor-online.net
X-Trace: DXC=`IgASfF@e``016@cHD@m;
 j4IUK<Cl32<a4Fo<]lROoRa8kF<OcfhCOk5QcE1AObASlPCY\c7>ejVhmV4_;
 ITiTRb`FMm\WQ8Rlc
X-Complaints-To: usenet-abuse@arcor.de
X-Original-Bytes: 1982
Xref: number.nntp.dca.giganews.com comp.lang.ada:184592
Date: 2014-01-29T23:53:35+01:00
List-Id: <comp.lang.ada>

"Randy Brukardt" <randy@rrsoftware.com> wrote:
> "Dirk Heinrichs" <dirk.heinrichs@altum.de> 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.