how to use git to emulate Interlisp-style versioned file system

[masinter]

This seems to be critical path. How do we check in files with multiple versions? The Interlisp model is important for the file package and other tools to work. There are other requirements but the most difficult:

a) it must be possible to open old versions and new simultaneously
b) should preserve last good version number, and file modify date/time (including the timestamps on the files (Including on the files I copied and moved around on my ICloudDrive.
c) It should feel "natural" from the git point of view. only one name per source file.
d) it would be nice if we could insert releases before the committed history, after the fact
e) should integrate with DSK.c code that uses file.~11~ versioning method

I'm thinking of an addition called "gitversions" which would clone (read-only) older versions as file.~n~
and a change to the repo to put the file mod dates in the repo.

From @nbriggs --

https://github.com/danny0838/git-store-meta

The Interlisp file system is based on BBN TENEX's https://github.com/PDP-10/tenex
@larsbrinkhoff ?

[johnwcowan]

I just don't think that's going to work. No VCS that I know of, certainly not git, preserves timestamps. I think it's better to take the more modest road and be Emacs-compatible. I'll pull together exactly what that means when I have a chance.

[masinter]

we had a long discussion on Monday's zoom call which convinced me it was worth looking into feasibility of preserving not only mtimes but also "version number", that would save even if gitignore *~ (I e, we never git add foo.~nn~

Per the discussion about file metadata in the meeting today, here's the git hook package for file metadata that I noticed:

https://github.com/danny0838/git-store-meta

I haven't looked closely at it, but at least it shows that what we want can be done without too much complexity.

If anyone else has a better suggestion... speak up...
I thought about it for a while, and came to the conclusion that I needed to write down the requirements and thus this issue.

Now, there is a fallback which is easier: lisp source files and compiled files have timestamps in text (remember no one edits Interlisp files by hand), so you can reset the timestamps on those if not exactly. (usually it's stuff like comparing two directories
or seeing which patch files were added after the directory.

Now maybe those utilities would be written differently today but it's just this current situation, trying to figure out which of several copies are the latest -- when we need some tools right away.

[masinter]

https://github.com/Interlisp/maiko/issues/7

Having two separate issues lists between medley and maiko was a beginner's mistake.

[masinter]

Conclusion: file versions are a local workspace issue. Files in GitHub will not have version numbers, GitHub has a different model of version management. You don't want Lisp versions to have separate histories. When you start working on an issue, create a branch and pull it. as you're working make local versions. as you're working commit and push.

interlisp sources, .DCOMs have filecreated inline metadata; sysouts have makesys dates. Don't know about tedit files.
Rather than making everyone to run a utility to change the dates to match their filecreated dates, change COMPAREDIRETORIES and loading patches to use the embedded dates instead.

[nbriggs]

I think you're conflating dates and version (numbers).

[masinter]

They are both aspects of the Medley "file system" that aren't preserved though github.

[masinter]

Here's a way of storing old versions in github i've been thinking off.
Take the list -l combined with shasums to create a list of all files in the repo, sorted by their file creation dates (*).
then, starting with a branch which has no files in it at all, in order of date, copy that file into the repo (but without version numbers, git add it with a take that includes the full file name (including version).
The result is that there is just one version in the repo, but all the versions are there.

We could do this with files going back to early 70's Interlisp-10, then the 70's snapshots from PARC backups, the envos updates, which might be interesting.

Using the shasums to help with files moving or just being deleted.

[masinter]

This might be better in Interlisp hooked into a new device type?

if I have file (latest version) and file.~23~ and file.~22~ (two older versions) then (assuming I have *~ in .gitignore)

• save (mv) file to file.~24~ unless it is identical to file.~23~
• for each old version MM in increasing order move file.~NN~ to file and git commit it with a note with the hash of file and the file verson number and modification date.

this will put all the old versions in the file history.

====

the second app unwinds the first by fetching old versions and restoring them with version numbers in order. ideally these would be repository-specific git extensions that did this automatically when committing changes.

You pass in a depth -- how many versions do you want to go? Or a timestamp (no versions before such and such date.)
You might have to deal with conflicting version numbers if files were moved around. It's great to preserve version numbers when we can but not imperative.

--

[johnwcowan]

This all seems like excess complexity to me. Here's a more straightforward approach:

Notice when files are under version control (in a directory whose ancestor has a .git subdirectory), and then instead of renaming and deleting, use git rm and git mv. Supposefoo.~1~, foo.~2~, and foo exist.

• If you want to create a new version of foo, then do git mv foo foo.~3~; touch foo; git add foo.

• If you want to remove the latest version of foo, do git rm foo; git mv foo.~2~ foo.

• If you want to remove other versions, git rm them.

Periodically do a git commit -m ""; git push. This is the only part that requires a connection to GitHub. All this can be done transparently in maiko, though as always there are issues on Windows.

[masinter]

I don't think it's necessary to have foo.~3~ as a separate entry than foo in the repo.
it's just a little bit of extra metadata. It's just the initial setup that's harder. I'm working on getting some git help.

[nbriggs]

I don't think people should generally be working directly in the git repo. It's only when you intentionally make a version that you want to make public that you should put the file there, and as a git user I certainly don't want Medley "helping" me to keep a repo, especially if it's MY repo that's not the Medley repo.

…

On Oct 23, 2020, at 12:32 PM, Larry Masinter ***@***.***> wrote: I don't think it's necessary to have foo.~3~ as a separate entry than foo in the repo. it's just a little bit of extra metadata. It's just the initial setup that's harder. I'm working on getting some git help. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/17#issuecomment-715539651>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWMMK6B6W3MIPN34N2LSMHK4BANCNFSM4QKEATAQ>.

[masinter]

I find myself switching between machines (windows, pi, mac, chromebook... )
and backing up to github on a personal branch or fork is useful but I could
instead use a personal dropbox or a home NAS box on my home router so that's not a big use case.