git and medley files and version numbers

[rmkaplan]

We are switching so that the repository itself will mark significant check-in milestones in a way that goes across developers, so the version numbers in my clone only represent internal stages of my own development sequence. They should be ignored (entry in .gitignore should be uncommented), and eventually only the most recent unversioned file should be noticed and uploaded.

(The version numbers that are now in the repository probably should be retained. Many of them reflect my development sequence before git, and so allow us to trace back to original sources if need be. But new version numbers have no global meaning.)

My understanding is that if I pull an update to a locally versioned file, that the link to the current versioned file will be broken but that the old contents will be preserved under that version. And that a relinking utility (can that be done as part of the pull?) will essentially assign a bumped version number to the new download.

Which is good…except for version 1. Currently version 1 is represented only as the unlinked unversioned file, so that will get smashed by the pull. Can that be fixed as part of the pulling?

This leads to another proposal:

Perhaps what we need is a git package inside medley that knows about the medley conventions, figures out how to rearrange things for compatibility if needed, and then issues git commands into a lower shell.

E.g. a git-pull function inside medley might provide more control over the interaction between medley conventions and git conventions than git currently (or easily) provides. Among other things, it could also set the directory dates to filecreated dates of pulled files.

It might also be useful to have a few medley UI tools analogous to local-file tools to help bring git into the residential framework. For example:

git-files? as an analog to files? to interrogate about the state of files that have been saved from the current sysout to the local system but haven't yet been pushed. The askuser could have options like forget, add, commit, save (=add/commit...), push etc.

git-cleanup calls git-files?, to determine what to do, then pushes.

load and loadfrom could also be modified to check against the repository and warn or ask about pulling when the repository has an update to the local version.

[masinter]

https://github.com/Interlisp/medley/discussions/categories/github-use
and https://github.com/Interlisp/medley/discussions/categories/configurations-and-releases
have prior discussions about these topics. I moved them to "Discussions" because it seemed like the requirements weren't clear.

Yes having some tools to integrate medley's view of the file system might be helpful.
But I think most of what we want can be integrated into git.
First I think a fixup of a single file to

1. (a) reset the file date to match the date of the FILECREATED of the file (for all versions)
   2, if the (from llisp side) highest version of the file (from unix the unversioned file) is the same length and content as the (from lisp next-highest version) (from unix the highest version) then (from lisp) delete the highest version (from unix replace the highest numbered version with a hard link to the unversioned file

As far as experimentation with gitignore *~ I'll give you the same advice I need to take myself: Always work in a branch or fork. Make a new branch or fork, call it whatever, and try it out!
When you are happy with the result, do a pull request. (Easier said than done, I know)

[rmkaplan]

Why would you ever want the repository to have medley version-numbered files that only have meaning as intermediate stages in a local development sequence?

…

On Dec 26, 2020, at 4:37 PM, Larry Masinter ***@***.***> wrote: As far as experimentation with gitignore *~ I'll give you the same advice I need to take myself: Always work in a branch or fork. Make a new branch or fork, call it whatever, and try it out!

[masinter]

I made a new branch of the medley repo called "ignore-versions" and pushed it. We can work in this branch together.
If you're using the github for desktop app you should be able to switch to it by clicking the "current branch / master" button (if it's done a "Fetch Origin" recently -- if you don't see it, click on "fetch origin"). Try making a new version of a file or two, adding them, committing, and pushing. I'll do the same. I'm not entirely sure how this will work with us working at the same time on the same branch.

We need to make a guide to working on the medley repo, for people who want to help out.

[rmkaplan]

I’ll give it a try, thanks.

…

On Dec 27, 2020, at 10:37 AM, Larry Masinter ***@***.***> wrote: I made a new branch of the medley repo called "ignore-versions" and pushed it. We can work in this branch together. If you're using the github for desktop app you should be able to switch to it by clicking the "current branch / master" button (if it's done a "Fetch Origin" recently -- if you don't see it, click on "fetch origin"). Try making a new version of a file or two, adding them, committing, and pushing. I'll do the same. I'm not entirely sure how this will work with us working at the same time on the same branch. We need to make a guide to working on the medley repo, for people who want to help out. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#108 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJ23C6WEMSXHDISYRTSW55FPANCNFSM4VKFQ4OA>.

[rmkaplan]

This could also be a package/filpgk issue, or a SEDIT-COMMONLISP/TEXTMODULES issue. MEDLEY-FIX-DIRS when it sweeps library has the side effect of causing SEDIT-COMMONLISP.DFASL and TEXTMODULES.DFASL to be loaded. Also, the file EVAL-WHEN-PATCH.

I think this is some goofiness in the specification of filecreated and how it is parsed. Extracting the filecreated information, if that's what it is, should not cause other files to load. I noticed the EVAL-WHEN behavior a long time ago, never figured out what John was kludging around for.

[masinter]

I went down the road of writing the "fix medley dirs" in Interlisp, but it's pretty hopeless.
There are too many bugs (PACKFILENAME.STRING, DELFILE of intermediate versions) to write this in Interlisp; the maiko {DSK} code gets confused.
I think the right thing to do is to either run this on the unix side or produce a "doit" script from lisp.

[masinter]

I'm going to move this to the GitHub "discussion" and open some Issues that are more specific.

1. Document MEDLEY-UTILS in Internal/Library: MEDLEY-FIX-DATES and MEDLEY-FIX-LINKS.
2. Change loadups to fix links before running
3. change medley-fix-links to be more localized and safer