🚀 go-pugleaf

I work with unix people a lot.  They have an elaborate protocol in 
place to have different source versions of programs.  They have 
tools, such as the gnu rcs suite of programs, to manage these 
versions.

I find, after a lot of thought, that I am sympathetic to the idea of 
source control also.  I have tried to think of what it means in the 
Oberon environment.

Page 110, "Project Oberon", discusses the generalized piece chain, 
to support looks.  This existing representation of a document within 
Oberon already supports multi-file documents and updates.  The 
existing Text module collapses all of these different pieces into 
one file when a text is stored.  In addition, when a text is first 
opened, all of the pieces point to one file.

In order to support version control, the only major changes that I 
envision are the ability to store the file information in the piece 
dictionary, and to reconstruct this upon open.  The new version of a 
text would consist of the piece dictionary header, and the relevant 
portions of the internal file that has newly typed text.  

A file that differed only by the font markup would only have a piece 
directory, and it could be very small.  Indirection in the piece 
directory itself could be used for additional size reduction.

In conjunction with an extension to the file naming conventions, 
this would immediately yield a version control system.  The 
vulnerabilities are that files are no longer independent.  That is, 
the deletion of an old file can be a catastrophe.

I wonder if this was studied at ETH, and/or what other people think 
about this.

-- 
http://ccwf.cc.utexas.edu/~mcintosh
... seeking old comp.lang.oberon articles