Re: Open source Ada OS?

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

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
news:b1da7195-8f26-463e-a297-195131a615f0@j32g2000yqc.googlegroups.com...
...
>CVS would not even help do that because CVS, being rubbish, has per-
>file histories as opposed to per-project history.

Per-project history is also rubbish. I've never seen any version control 
system that actually would solve my problems rather than replacing those 
problems with a large set of new ones.

In the entire history of RRSoftware, there have only been two projects: 
Janus/Ada and Claw (ignoring a few hobbyist things). But these aren't 
monolithic entities. Janus/Ada, especially, over its history consists of a 
dozen or so separate tools, several in multiple parts, targetting about 25 
different targets. (Many of those targets are obsolete now.) Different 
targets were/are released at different times. If you treated those as 
*separate* projects, then all of the shared files (the majority) end up 
duplicated; if you treat those as *one* project, then you lose the ability 
to have separate releases for different part of the project. And in either 
case, there is no automated support for files that are related (and need to 
be kept consistent) but have different contents. (An example of this latter 
is the target description packages; these all contain a set of types and 
constants whose names have to be the same but whose definitions are 
different for each target. Some also contain subprograms with different 
bodies for different targets.)

A proper version control system would provide automatic warnings to the 
owner of a file/subproject/whatever when a related file needs to be changed. 
No such thing existed (or exists, so far as I can tell), so we built our own 
as a front-end to PVCS (later converted to CVS). That just uses CVS as a 
fancy difference engine; file relationships are kept in our manager. The 
problem, of course is that the thing is fragile and monolithic.

But none of the new VCs make any serious attempt to solve this problem. 
Branching would do it if there was a way to keep multiple ends active at the 
same time, without restrictions, and in additional kept track of when one 
end is out-of-date with the others.

Merging, however is never a solution. It just moves the problem from 
whereever it is now to the merge process. And automated merging is a 
disaster waiting to happen (and it happens often in my experience) - 
different targets get merged, bug fixes disappear, and the like. And manual 
merging is not a solution: it is just too time-consuming.

A related issue is "freshening" of working directories. I never, ever want 
to trust that what is in the VC is correct. It *ought* to be, but it often 
isn't and as such I never want to assume it is correct. Thus getting of 
files from the VC must query whenever it is about to change a file and ask 
for approval (that process has saved me many times from reintroducing bugs).

Finally, like all worthwhile programming tools, it has to be written in Ada. 
:-) That way, *I* can port it to the targets I need it to run on, I can fix 
it if necessary, and so on.

OK, the last is much less of a requirement than the others, but I do have 
much less trust in software not written in Ada. I use some of course because 
I simply don't have time to write my own OS, browser, and accounting 
package. (I wish I did.)

                      Randy.