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: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.