Re: Open source Ada OS?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 26 Jan 2011 17:02:46 -0600, Randy Brukardt wrote:

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

The point is that it is the project of which history you wanted, individual
files are of no interest when taken out of the project's context.

> 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;

The "shared sets files" must be organized projects, obviously. This is the
strategy we are pursuing at cbb software. There are hundreds of projects
and very complex dependencies between them. We built our own project
management system on top of Perforce in order to maintain that and to carry
out automatic builds.

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

In our case it t is not a warning, but an error. E.g. if you have a diamond
diagram of project dependencies:

     A
    /  \
   B   C
    \  /
     D

then the tool does not permit different releases of A to come together in
D.

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

Perforce is just too slow and poorly designed (CVS, Subversion, MKS aren't
any better). A good system shall have a virtual file system and hold no
local copies at all. If this is not given, no reasonable project management
system can be built on its top.

> But none of the new VCs make any serious attempt to solve this problem.

Yes. They look like hobbist's projects of people who never had to maintain
a code base delivered to dozens customers with the need to track down older
releases.

> Merging, however is never a solution. It just moves the problem from 
> whereever it is now to the merge process.

Yes, we just disallowed merging at all. The tool does not allow concurrent
check-outs. Branching is not welcome either.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de