Investigate Monticello and related tools for the Smalltalk environment

[johnwcowan]

Squeak and related Smalltalk implementations have the same version-control problem as Medley for distributed development: Git cannot properly diff or properly merge the textual representations of two different images. If anything, the problem is worse in Smalltalk because (a) there is only one text file, not many, and (b) not all bits in the image correspond to code in the text file: some pre-1980 bits were set directly in the image before the text file was started.

However, Squeak uses a version-control system called Monticello that supposedly solves this problem. I know almost nothing about it, but I'm going to investigate it as I can, along with possible alternatives, and report back here.

[masinter]

It's worth looking at alternatives to 'git' but I think we'll have more impact trying to work with it.

https://github.com/features/issues/ #536

[lassik]

Git can store binary files, and can use custom diff and merge tools. It might be possible to make do with that.

[nbriggs]

Git can, and we went that route for a while, but the issue is github and their web interface doesn't let you (as far as I know) provide custom tools (or scripts) to run on their server...

[lassik]

Oh yeah, that's probably right.

However, GitHub is even less likely to support any non-git Monticello-style tools. You'd have to host the version control repo at a separate website, or use diff/merge tools on local machine only. Maybe it'd be enough to have local machine tools + a script to churn out HTML reports of the git history for display at a public website.

[masinter]

I think we can make things work if we use different Lisp-based utilities to compare and merge files.
The problem is less "GitHub" and more "GitHub desktop"

[lassik]

Right. Happily, GitHub (and all other git hosts) are 100% compatible with command line git. You could even call out to git from the emulator's file handling commands or something.

[johnwcowan]

Writing down now what I've been talking about the last few weeks:

1. The git repo is a separate directory from the source file directory.
2. A source file is represented on the git side as a directory, not a file.
3. Each definition (in the sense of File Manager) in a source file is represented on the git side as a file.
4. The purpose of this design is so that diffs are bounded to a single definition.
5. Each such a file is named nnn_type_name, where:
   1. nnn is an index representing the position of a definition in the source file;
   2. type is the File Manager type of this definition;
   3. name is the name being defined.
6. As a special case, the fileinfo and filecoms are in git file 000. The file map is not represented.
7. If a definition is inserted between index 4 and index 5, it is numbered 4.5, and so on.
8. Two operations from Interlisp:
   1. Disassemble a source file into the local git repo.
   2. Assemble a directory in the local git repo into a source file, reconstructing its filemap.
9. Figure out which git operations to make available from Interlisp (depends on the workflow we settle on)

[masinter]

This design seems like it's feasible, although there are lots of details. I'm not sure it's worth it.
Applying the "Interlisp" file manager methodology to other late-binding Lisp-like languages like JavaScript and Python might have a lot more impact. Or even on top of SBCL.

[Kirtai]

Just a note that Cuis, a fork of Squeak focussing on simplicity, uses a different approach that works fairly well with git.
I don't know if it would be usable here though.

[masinter]

This is an interesting discussion, but I think it's a separate project.
We might start with the TEXTMODULES library package, which converts two ways from "file manager style" to "text style" and back.