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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5894fe67040038b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-07 14:20:45 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Attributes 'Version and 'Body_Version Date: Wed, 7 Nov 2001 16:49:52 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9scaa3$b7t$1@nh.pace.co.uk> References: <9s9iti$g$1@nh.pace.co.uk> <5ee5b646.0111061939.595b61be@posting.google.com> <9sbb1f$2bm$1@plutonium.btinternet.com> <9sboee$42f$1@nh.pace.co.uk> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1005169795 11517 136.170.200.133 (7 Nov 2001 21:49:55 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 7 Nov 2001 21:49:55 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:16021 Date: 2001-11-07T21:49:55+00:00 List-Id: Well, as I said elsewhere, there's no substitute for formal CM and understanding your own software. I understand the case you are describing and I don't think I'd expect the compiler to be able to figure out that I reverted to some prior version of a subprogram. That's a bit much to expect from a poor, dumb compiler! If you need that kind of version control, it seems to me you're going to have to apply some human intelligence and Roll Your Own version numbering scheme. I don't see the '*Version as something to take advantage of in rapid iterations of the EditCompileLinkRun Development Methodology - but as something you might use in conjunction with formal CM in environments where you have possible multiple versions of a subsystem or you are using it to control the artifacts of what a subsystem creates. (Recording version numbers in the output from a subsystem.) But is it a) impossible and/or b) undesirable to have the Something'*Version increment with every compile? It might be nice to know that a unit you are calling is a later compile or earlier compile than the one you know about rather than the only information you have is that it is *not* the one you know about. You still need to be able to answer the question "What can I do about it?". You can't do much unless you know something about what changes happened between versions. When you *do* know what the differences are, you *might* be able to make some use of the ordering of the versions. Just an idea that might be useful.... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Larry Kilgallen" wrote in message news:bgYJjEmY5R3$@eisner.encompasserve.org... > > Then what happens if one rolls back SubTwo to what it used to be, > but retains the changed version of SubOne ? The result we have is > _logically_ between the original and the first modification, but that might > be hard to achieve in the sort order. Or what if we make _another_ > version that has the original version of SubOne but retains the > change to SubTwo ? How does the value of _that_ string relate > to the value of the one whose context is vice versa ?