Re: need help learning Ada for a modula-2 programmer

["Randy Brukardt" <randy@rrsoftware.com>]

"Dirk Heinrichs" <dirk.heinrichs@altum.de> wrote in message 
news:lcbc0j$cci$1@online.de...
> agent@drrob1.com wrote:
>
>> with Ada.Calendar; use Ada.Calendar;
>> Package timliba is
>>
>> --  REVISION HISTORY
>> --  ----------------
>> --   6 Oct 13 -- Converted to gm2.  And changed its name.
>> --  19 Jan 14 -- Converted to Ada.
>>
>
> You've already received some valuable on-topic replies, so here's an off-
> topic (but hopefully as valuable) one ;)
>
> 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. 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. 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).

The point about merges is correct, except that it really isn't a problem 
with a manual merge (what's one more difference out of dozens?). Assuming 
you have a proper tool for doing those (a multi-window editor with a good 
window-comparison tool), there is no problem. I'd agree that an automated 
merge might have problems, but for me, the idea that an automated merge is 
of any value is laughable. For an automated merge to have any value, it has 
to know all of the contents of the two new files and the contents of 
whatever file they originated from. But that latter item is unknowable in 
general - even the programmers don't know it accurately. One might imagine 
that very strict rules about version control use would help; but I've never 
been on a programming team that didn't break whatever rules were in place 
from time-to-time. And some people (like my co-founder) were completely 
incapable of following any rules whatsoever, no matter how easy and 
unobstrusive they might be.

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.

                                                 Randy.