Re: GNAT corrupted builds with below second changes

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

On 16/03/2018 04:27, Shark8 wrote:
> On Thursday, March 15, 2018 at 1:59:21 PM UTC-6, Bojan Bozovic wrote:
>>
>> 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).
> 
> I agree that a versioning FS is needed; but this only addresses the specific issue raised here (the timestamp-resolution) and even a versioned FS is inadequate to the general problem.

Yes, versioning files /= versioning projects

> Take, for example, moving a file or directory and the impact that has on a makefile/build-system: it invalidates the entire object in question and destroys the ability to build. -- As you can see, using the FS as an anemic & ad-hoc DB is simply not addressing the entire problem.

Moving directory on the project level is checking out everything for 
delete, then committing delete, then deleting items from the project, or 
all project.

> We could [and should] store them as parsed, processed semantically-valid structures. (Yes, there *should* be an interface for import/export to files/text; this operation could be done by the Types for the structure themselves as serialize/deserialize operations.) -- While it's possible these structures could be stored in a mere file, that's not handling things very intelligently: if the above structure is suitable to being stored in a database then [with a little cleverness] we inherit an entire entire system for dealing with ensuring that data is valid.

Yes, an OO persistent storage.

BTW, RDBMS is notoriously poor on that. Relational algebra is no help 
here, at all.

> Or something like that. (Of course these sorts of manipulations on the source/DB should NOT be visible to the user, but are merely here to disabuse you of the notion that all editing/manipulation must be done as text.

No, that would be a text buffer with tags for colorization and hyperlink 
references.

> Aside from all this, the usage of DBs can be a huge improvement to FS-based systems precisely because of properties of the DB. Take for example this alternative to "Continuous Integration" from the mid 80s -- http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26.2533&rep=rep1&type=pdf -- by partitioning the project into workspaces and using a hierarchical database, only merging "upward" when everything on the "current level" is consistant [compilable], you end up with a DB where the root node *ALWAYS* has "the last compilable version". (Combine that with versioning and you have a record of EVERY COMPILING VERSION; *BAM!* no messed up/non-compiling crap in your repository.)

Instead of partitioning projects decent software engineering uses the 
project (library) as a partition. The larger projects consist of/depend 
on projects versioned in a way that incompatible versions cannot be 
mixed. Any IDE, any OS distribution follows this model, only file 
versioning systems do not (Rational ClearCase does).

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