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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6df3ec0dff30c185 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!94.75.214.39.MISMATCH!aioe.org!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Open source Ada OS? Date: Wed, 26 Jan 2011 17:02:46 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <4d3f3be3$0$22088$742ec2ed@news.sonic.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1296082970 22080 69.95.181.76 (26 Jan 2011 23:02:50 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 26 Jan 2011 23:02:50 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-RFC2646: Format=Flowed; Original Xref: g2news1.google.com comp.lang.ada:16723 Date: 2011-01-26T17:02:46-06:00 List-Id: "Ludovic Brenta" 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.