🚀 go-pugleaf

The non-branching version case is very simple.  File names would 
have more structure.  Note that files are now read only.  

E.g.

	Memory.Alfred.Mod
	Memory.Index.Mod

	BTree.Alfred.Mod
	Btree.Index.Mod

	TCP.Alfred.Mod
	TCP.Alfred.Mon.Mod
	TCP.Alfred.Tue.Mod
	TCP.Alfred.Tue.Mod;2	(* ok, so I've used VMS *)
	TCP.Alfred.Tue.3.Mod
	TCP.Index.Mod

	TCP.NT.Alfred.Mod
	TCP.NT.Index.Mod

This immediately gives named versions.  

During routine workday, I open the last useful version:
	Edit.Open TCP.Alfred.Tue.3.Mod

Then I edit the menu bar.
	MultiUser.Alfred.Mod

Then I make changes according to the plan, and save the file.   
Edit.Store works as always. The file is small,
and has references backward to earlier versions.  

Texts.Open, .Load, .Save, .Store are the only places where Oberon 
source changes must occur.  All the editing tools remain the same, 
since we abstracted Text very well indeed in the forgotten past.  
AsciiCoder uses a hack, and would need some change to adapt to this. 
 This hack might indicate a need for a subtle change in Texts.

A new command, similar in placement to EdiT.StoreAscii, is added to 
EdiT.  This is Edit.StoreOneFile.  The implementation
is profoundly similar to StoreAscii.


Now I do:
	Compiler.Compile
		MultiUser.Alfred.Mod
		TCP.NT.Index.Mod ~

For the branching case, why, everything still works with no change 
in thinking.
File renaming and deletions become more interesting.    
---------------------------------------------------------------------
--------
Doug Danforth writes:

  Forgetting a little about the details of the implementation,
how do you see this being used?  What do you see the process to be?

-Doug

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