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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.107.131.8 with SMTP id f8mr4777904iod.8.1521143959690; Thu, 15 Mar 2018 12:59:19 -0700 (PDT) X-Received: by 10.157.95.23 with SMTP id f23mr501670oti.12.1521143959561; Thu, 15 Mar 2018 12:59:19 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!maths.tcd.ie!newsswitch.lcs.mit.edu!ottix-news.ottix.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!r195-v6no55821itc.0!news-out.google.com!h73-v6ni86itb.0!nntp.google.com!r195-v6no55820itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 15 Mar 2018 12:59:19 -0700 (PDT) In-Reply-To: <2e250363-97a3-45bd-948e-081e24d70655@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=87.116.179.50; posting-account=z-xFXQkAAABpEOAnT3LViyFXc8dmoW_p NNTP-Posting-Host: 87.116.179.50 References: <2e250363-97a3-45bd-948e-081e24d70655@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <61dc87c3-30f1-4bbb-9125-89ec6e5dfc2e@googlegroups.com> Subject: Re: GNAT corrupted builds with below second changes From: Bojan Bozovic Injection-Date: Thu, 15 Mar 2018 19:59:19 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:51005 Date: 2018-03-15T12:59:19-07:00 List-Id: On Thursday, March 15, 2018 at 7:52:20 PM UTC+1, Shark8 wrote: > On Wednesday, March 14, 2018 at 4:36:34 AM UTC-6, Alejandro R. Mosteo wro= te: > >=20 > > I will guess here that the timestamp being used has=20 > > second precision. This leads to supposedly up-to-date builds that=20 > > aren't, among other funny effects. >=20 > This is one reason I advocate a DB-based solution rather than an FS-based= solution; after all, the FS solution *IS* simply using the FS as an ad-hoc= and anemic database, and using the timestamp-field this way is essentially= analogous to querying a 'time' column when what we *REALLY* want is a 'ver= sion' column (not "1.2.3" but more like "build # X"). >=20 > A lot of problems with build-systems come from (a) using the FS as an ad-= hoc DB, and (b) the differences in the FS like "/ vs \ vs :" directory sepa= rators, or case-insensitive vs case-sensitive. Versioning file system is then what's needed, and that has been in VMS/VAX-= VMS/OpenVMS since seventies (and since seventies, VAX had 128 bit integers = as well). There's no good reason mainstream OS don't have it (like Windows,= Linux and OS X), it's absent only due to inertia. In linux there's NILFS b= ut it's not used in mainstream distributions. DB is partial solution, as fi= les belong to the file system, not the database.