[Oberon] [EXT] Re: all in one git tree

[D EMARD]

HI

I will try to answer some questions, maybe some views are
not appropriate as I don't know what data oberons have,
here's my views under some probably incomplete assumptions.

Goals are

To preserve better old OS and its development history.
by building the tree which in traceable form replicates previous
development efforts.

To very precisely (in form of timestamps and code line differences) provide
answers why and when is some function modified and how we came to its
current state.

To collect in one database all most major code branches known of
some value to someone e.g. if still actively in use or
being developed now.

To provide technologically advanced possibility to collaborate
and share code changes, but never to force it. When code is
shared, it will be traceable to a source it was taken from,
time and who were developers.

To share code changes at fine granularity down to each line.
Better than sharing whole zip or mailing each file. But never
to force developers to anything.

Object of sharing can be:

ASCII only: Information of highest intelectual value is content of
ascii lines of the programming language written by developers. It is
basic material for collaboration and code sharing. Oberon as
programming language is expected to contain high % of those.

Near-ASCII If we have almost ASCII-only source that just has header
with font name,
I suggest to convert it to ascii-only in order to be fully traceable
by git versioning system.
In the git keep header as ascii comment (* font: helvetica *)
and provide a simple shell/python/bla converters for 3-4 common OSes
(linux/windows/apple/oberon) which can convert back and forth (* font:
helvetica *) line
into binary representation for exact binary upload to oberon machine.

Mixed content (binary from user GUI with occasional ASCII)
for example CAD drawing, user clicked and dragged mouse and now
it is picture of 3D object. Those files are useful and git can't do changes
diff on them. It can just store them, this can be treated as binary. When
they change they will have date and commit note, but entire new content
will be commited.

Binary-only content like 32032 compiler.exe which compiled first oberon or
ROM BOOT images is just a "ballast" required to make language complete
enough to run on machine. Store it as-is, noone will hexedit such blobs anyway.

Who will maintain?

Normally someone who initially assembles most significant branches of oberon
to a git tree is the best one to keep it and take further changes from
others. Anybody
else with a click can make his own independent fork, make change and request PR
to main tree. If first developer becomes unavailable anybody with a fork can
continue maintainance. Of course even forks can be fork-forked and branched in
parallel but I hope with a near-complete repository that contains
almost everything,
this should not happen (too often :)