Interlisp.org
Finish migration from Dropbox to Github for release #49
Replies: 34 comments 3 replies
-
|
Actually, I don’t think this is true. There is an environment variable LDEINIT that can be set to the name of the site greeting file before lde runs. The greeting file can be anywhere in the file system, does not have to be in /usr/local/lde/.
… On Oct 17, 2020, at 7:17 PM, Larry Masinter ***@***.***> wrote:
There is a configuration variable in the sysouts that "knows" that site init files (e.g., SITE-INIT.LISP) get installed in /usr/local/lde/. If we move that we need to update whatever variable it is that holds that knowledge -- except we can't do that to the original lisp.sysout.
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, Ron is correct, I was not. (GREETFILENAME) in APUTDQ does so LDEINIT overrides the default location and name. |
Beta Was this translation helpful? Give feedback.
-
|
"how to deal with files that have both a lcom and a .dfasl" As long as they correspond to compilable source code, is it necessary to store such compiled binaries in the repo? (Other than the sysouts for bootstrapping) Ones that only exist as binaries are a more complex question. |
Beta Was this translation helpful? Give feedback.
-
|
On this issue, it should not be the case that a given source has an LCOM and a DFASL, that should trigger a warning if not an error.
That would lead to confusion if one is updated but not the other—not clear which code would get loaded.
That was one of the issues I tried to resolve in the lispcore cleanup.
I presume (I haven’t checked) that this can happen if someone calls either the LCOM or DFASL compiler directly, as opposed to letting CLEANUP decide based on the FILETYPE property. Maybe the compilers should also do prechecks to make sure a file of the other type doesn’t already exist.
… On Oct 18, 2020, at 7:59 AM, Kirtai ***@***.***> wrote:
"how to deal with files that have both a lcom and a .dfasl"
As long as they correspond to compilable source code, is it necessary to store such compiled binaries in the repo? (Other than the sysouts for bootstrapping)
Ones that only exist as binaries are a more complex question.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-711200538>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJU6H4P7DCIZP7FVATSLL7FTANCNFSM4SUYIG5A>.
|
Beta Was this translation helpful? Give feedback.
-
|
When a source file and a compiled files both exist, a LOAD should check the dates of the two files and load the one with the latest date. Of course, this can be a problem when a bunch of files are copied and their dates get changed. |
Beta Was this translation helpful? Give feedback.
-
|
GitHub doesn't preserve file dates, and while there are extensions that do, not everyone will load them. LOADing the source instead of the compiled version isn't a good idea for the low-level system code (anything starting with LLxxx or Axxx). |
Beta Was this translation helpful? Give feedback.
-
|
Even for my own systems, I wouldn’t want a symbolic file to be loaded secretly when the call to LOAD explicitly specified a compiled file (e.g. FOO.LCOM, or from a FILES command in another file). I want a file-not-found error, as has generally been the case, so I know that somehow a CLEANUP missed a compile. I don’t want to be implicitly running uncompiled functions. Separately, I might want to be notified if the latest compiled file is not compiled on the latest (filecreated-date) symbolic file, but in some instances I might well want that behavior, to go backwards in a debugging sequence. I.e. it should not be an error. In terms of dates, as noted, copying files from one place to another makes it so the local directory date is the copy date and doesn’t reflect the actual creation date as marked in the file itself. I wrote a simple function in COMPAREDIRECTORIES to change the directory dates to match the timestamp date. Maybe that should be moved into the basic system and applied automatically in some way when files are pulled or first opened. But the directory dates are mostly just a hint, the conceptually important thing in the local file system is that the local version numbers should be monotonically related to the filecreated dates. (Unfortunately, TEDIT files don’t have an internal filestamp, which makes them hard to track. That should be fixed.) Within a given local environment, if Medley source files and compiled files are managed consistently by the file package (MAKEFILE, CLEANUP) and not modified with some other internal (TEDIT) or external editor (EMACS), the filecreated dates should always be accurate and the mapping to local file versions should be monotonic. |
Beta Was this translation helpful? Give feedback.
-
|
@Kirtai -- nothing we have should exist as only the binary. Compiled code should be stored in the repo because it can be a very delicate process to correctly produce compiled code that depend on (Lisp) system interfaces (and many "simple" packages DO have dependencies on the system exports) |
Beta Was this translation helpful? Give feedback.
-
|
I wasn't aware that it was that difficult to build the code. |
Beta Was this translation helpful? Give feedback.
-
|
I think the current state is "we don't know" how extensive the problem is, until we go through all of the source files and try to compile them in a vanilla lisp.sysout and tested them (if we can find or make test files for each). |
Beta Was this translation helpful? Give feedback.
-
|
It really would be a different mode of working. If I am working on one issue and someone else has fixed something else, I don’t want to have to recompile their changes in order to advance on my problem.
Interlisp has always been an incremental environment, where things can be updated for the most part independently. That’s always been a distinguishing and valuable attribute. We can patch on the fly.
This is not to say that it wouldn’t be good to know that every file has its dependencies (that are not in EXPORTS.ALL) explict and correct.
But I don’t think that recompiles should be necessary to take advantage of separate but unrelated improvements.
… On Oct 18, 2020, at 11:00 AM, Larry Masinter ***@***.***> wrote:
I think the current state is "we don't know" how extensive the problem is, until we go through all of the source files and try to compile them in a vanilla lisp.sysout and tested them (if we can find or make test files for each).
On the one hand, we've found several instances of dependencies that don't have ***@***.*** require calls.
On the other, Venue went through several changes to the VM which required recompilation, so it seems likely there were some efforts to enable a mass (re)compile.
I thought it might be helpful to start with "LispUsers" packages (Issue #7 <#7>) but we'll need to test Library, Sources, Internal/Library before we can turn off saving the .lcom and .dfasl files in the github repo.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-711339101>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJIDQ6YTTGBOPIH25ATSLMUKNANCNFSM4SUYIG5A>.
|
Beta Was this translation helpful? Give feedback.
-
|
"Interlisp wasn't just a language or environment, but also a way of life." The 'git' way allows an enormous range of usage patters. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure about using ".il" as an Interlisp source extension -- it's used for other things, and in particular, for maiko we already have files checked in with that extension -- it's what the Sun C compilers use for inline assembler code (e.g., dspSPARC.il and dsp386.il) |
Beta Was this translation helpful? Give feedback.
-
|
.ilisp would be fine with me. .ilsp would be more Interlispy. .lisp should be used for Common Lisp. |
Beta Was this translation helpful? Give feedback.
-
|
OK. I presume that when the filesystem file is foo.ilsp the file commands variable will be FOOCOMS? Still uppercase? |
Beta Was this translation helpful? Give feedback.
-
|
Regarding organization -- for every other open source project I use I expect to do something that approximates "git clone or tar xf dist.tar" "configure", "make", "make install", and then work outside the project source directory. If I have changes to make to the system itself then I'd work in the git/source directory, and then send a git e-mail patch, or just a [git] diff, or attach a file or patch to an issue in their repo. Things that are more standalone that are worth sharing I'd submit using whatever mechanism the people working on the code have (sometimes e-mail to a mailing list with the file or a reference for it). So... thinking about how I'd use Medley in this style, I'd prefer that the "make install" step put the lde/ldex into $PREFIX/bin, that it install the fonts in something like (not thought through exact names here...) $PREFIX/.../Interlisp/fonts/..., that it install the lispusers and library packages in $PREFIX/.../Interlisp/{lispusers,library}, and the prebuilt sysouts in $PREFIX/.../Interlisp/sysouts, the whereis.hash and exports.all files in $PREFIX/.../library (or...) . It could also tell you what to put in your site-init file for DIRECTORIES, DISPLAYFONTDIRECTORIES, etc. etc. I don't need to "install" all previous versions of packages (I would like them to be there in the git clone directory), but I would like to have it install the hard-linked versioned and unversioned files for lispusers/library packages so that if I write a new version of something to my own working directory the version numbers are compatible. I'd probably be OK with an option to install the (most recent version of...) Lisp sources, so that Masterscope and the files package could find sources for system functions. I don't think merging LISPUSERS and LIBRARY provides any benefit, and has a big downside if the documentation that currently distinguishes between them doesn't get updated. |
Beta Was this translation helpful? Give feedback.
-
|
Currently, the function FILECOMS, which should be the canonical way of mapping from a filename to its commands, packs on “COMS” to the NAMEFIELD of the file. So FOO.ILISP gives you FOOCOMS, foo.ilisp gives you fooCOMS.
Do we want to allow upper and lower case versions of the same file, with different commands? I think not.
… On Oct 21, 2020, at 2:06 PM, Nick Briggs ***@***.***> wrote:
OK. I presume that when the filesystem file is foo.ilsp the file commands variable will be FOOCOMS? Still uppercase?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-713877324>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJNQDYV6RFG2K26KAXDSL5EMLANCNFSM4SUYIG5A>.
|
Beta Was this translation helpful? Give feedback.
-
|
current maiko DSK.c creates a case-insensitive file system even if the underlying file system is case sensitive. The proposal is that the file names from the Unix point of view should have lower case file names, by default. When we get to Unicode file names, then you need to match normalized (and lower case). |
Beta Was this translation helpful? Give feedback.
-
|
Well, for the original sysouts, the problem is that we moved the medley3.5/source library/ lispusers/ directories down a level, to lisp/sources lisp/library/ lisp/lispusers.
So those files are there from the medley3.5 level with the same identifying dates, but the FILEDATES path doesn’t correspond to the new directory organization.
The FILEDATES paths could be updated in those sysouts too, although changing those is a little scary.
I feel more comfortable making all of the filedates in the xx sysouts point to the copied files on lispcore, even if they weren’t overridden.
… On Oct 23, 2020, at 1:59 PM, Nick Briggs ***@***.***> wrote:
The original lisp.sysout, not xlisp.sysout, and it has
FONT -- FILEDATES : ((" 8-Nov-94 12:13:47" . {DSK}<lispcore>sources>FONT.;2))
and the original full.sysout has the same version of FONT in it.
> On Oct 23, 2020, at 1:39 PM, rmkaplan ***@***.***> wrote:
>
>
> Is this the original lisp.sysout or the one that I am making (xlisp.sysout) on top of that, from the lispcore files (because we can’t do the init.sysout)?
>
> However, since FONT didn’t change from lisp to lispcore/, the synchronizing/patching routine to make the xlisp.sysout does not load the version of FONT on lispcore (which would have the updated FILE property), even though lispcore/FONT is a copy of lisp/FONT (same dates) which is in the xlisp sysout.
>
> Is this a correct diagnosis of what you are observing?
>
> So we are straddling 2 worlds. One solution might be to have the xlisp synchronization code update the FILE property for files that it decides it doesn’t need to update, so that the xlisp and xfull sysouts consistently point to Lispcore.
>
>
>
>
> > On Oct 23, 2020, at 1:09 PM, Nick Briggs ***@***.***> wrote:
> >
> >
> > Hi Ron -- there's code missing in the lispcore.zip in your dropbox, you've pruned it down to one copy of everything and so we no longer have the versions of, for example, FONT that match the code loaded in the lisp.sysout.
> >
> >
> > > On Oct 23, 2020, at 11:29 AM, rmkaplan ***@***.***> wrote:
> > >
> > >
> > > I checked the lispcore/sources library/ and lispusers/ to make sure that I had already eliminated competing LCOM and DFASL files, and indeed I had done that. We don’t have that confusion in these directories, in the lispcore.zip in my dropbox. (I think there are still a few compile-source version uncertainties that I have not yet resolved for some of the DFASLs.)
> > >
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-715566486>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJPORK54YLAYS5ZZOE3SMHPHFANCNFSM4SUYIG5A>.
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-715578911>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWNSHQ5PCQ3XAIGYIW3SMHSX5ANCNFSM4SUYIG5A>.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-715586850>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLWWFEMLN2HI76ZD3LSMHVBRANCNFSM4SUYIG5A>.
|
Beta Was this translation helpful? Give feedback.
-
|
I declared success too early on the mail list, since the current github master isn't being used by Nick or Ron. From @pmcjones notes on meeting Continuous integration discussion… |
Beta Was this translation helpful? Give feedback.
-
|
I'm going to make another try at resolving the files in github issues, but hopefully this time documenting the changes I'm making. The first piece of surgery is aimed at the convention at PARC for shared file server systems to have a The GitHub changes are extensive but relatively easy to explain:
so far this has been pretty simple except the duplicate bin directories, which have different 'medley' startup scripts, neither of which is right after the move. The bin directories also had copies of led ldex (and other binaries. Since medley script is all that's left not machine independent and what's needed is a simpler startup script. Meanwhile I'll temporarily git mv bin/medley run-medley0 committing this to the anothertry branch took minutes but pushing it to GitHub was quick. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW I thought a little more about how I would like Medley version numbers to interact with git pushes and pulls.
In the sandbox on my working machine, I want Medley to be able to create new versions with updated version numbers in the standard way. The latest version would be the one without a version suffix, with its logical number inferred either from a hardlink to a different versioned-name or, if it is unlinked, then inferred as one greater than the greatest versioned-name.
When I decide to push to the repository, I think it would be OK to push up only the file with its unversioned name (the file with the logically newest content). It wouldn’t be necessary to push up the versioned-name history that I have on my machine—version-named files should be ignored in the push, the repository would never know about them. Presumably git would maintain its own history of unversioned filenames at the granularity of push events.
When I pull an (unversioned) file down from the repository and it lands in a directory that has a sequence of versioned files representing my personal work history, I want the pulled file to end up with a version number logically one higher than the local current highest version. That might involve some unlinking of the current unversioned-filename and linking to the pulled unversioned name to a new versioned-name. I.e., the pulling would act as if I had made the pulled version as a new version inside my local medley. It would add to my local history, not clobber it.
If this is compatible with the git model (which I have not internalized), then perhaps this could be implemented just by special wrappers of the relevant git commands. The repository itself would be clean.
… On Nov 7, 2020, at 12:41 PM, Larry Masinter ***@***.***> wrote:
I declared success too early on the mail list, since the current github master isn't being used by Nick or Ron.
I think I need help though to understand the requirements and turn that into a finite set of doable tasks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-723493103>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJONZ7Y3VWTH7NX5QODSOWWI5ANCNFSM4SUYIG5A>.
|
Beta Was this translation helpful? Give feedback.
-
|
My limited understanding:
Most of what we want can be accomplished by adding |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps the way to understand the git model (of repositories and commits and branches and tags) is to recognize that it is a weakly consistent replicated storage system with "update anywhere", where the contents are (1) a collection of objects, and (2) a digraph of named nodes representing the state of the collection of objects.
There is no technically enforced "truth" copy of the contents -- your copy of a repo is as good as any other copy of the repo -- the reference copy is a social construct.
Each time you commit to your repository, git creates another node in the digraph (representing a new state of the entire repository), proceeding from the current state (which is not necessarily the most recent state)
If you "push" your repository to another repository, or pull another repository into your repository, it will send/fetch changes and attempt to reconcile the digraphs -- asking for manual intervention if changes conflict.
A branch is just a human readable name associated with a particular node on a path in the digraph that is advanced automatically as you add nodes (or merge paths).
A tag is also just a human readable name associated with a particular node in the digraph, but it does not advance automatically as changes are made (you may explicitly move it, though).
Does this help?
…-- Nick
On Nov 13, 2020, at 11:26 AM, Larry Masinter ***@***.***> wrote:
My limited understanding:
a couple of things that distinguish git from other source code version control systems:
git separates local interaction with the model and interaction with the public" -- "commit" vs "push" and "fetch" vs "merge".
It's different enough to affect when you can do special actions.
actions (commit, push) don't just involve one file, they might affect all of the files in the repo.
there are hundreds of git commands, and a wrapper won't do, but there are git 'hooks' (see medley/.git/hooks for some samples)
branching (and subsequent merging) is the rule vs. the exception. Any system we invent for maintaining version numbers has to be prepared for the possibility of you (locally) switch to another branch and switch back, as long as you have no uncommited changes in the repo.
there's a file .gitignore that has a list of file patterns that are not considered as uncommitted changes, included in commits.
Most of what we want can be accomplished by adding "*~ to .gitingore in the repo. (The .gitignore is part of the repo)
That would mean that .git would normally leave the version-numbered files that Lisp creates alone.
That's the way in which the repo is "clean".
Second, write a utility -- call it 'fixversion' which reads the FILECREATED, finds the version number NN of the original, and creates a hard link to the file.~NN~ in the following circumstances:
there is no other file.~NN~ in the directory. Lisp will treat this as notice that file will be treated as version NN and no other versions are available
all the other versions are less than NN.
in other circumstances, it just leaves the directory alone.
Lisp will treat the file as version MM+1 (where MM is the max of NN for all the other versions)
You might want to restrict this to files whose FILECREATED (for source files or the equivalent for LCOM and DFASL) path matches, but I think Lisp tends to have unique file names and preserving version numbers is OK.
If you switch branches in your local repo and then switch back, you might lose all versions but the latest.
You could set the file modification date to the FILECREATED/compiled timestamp at the same time.
When to run the fixversion script is another question. It needs to run before Lisp enumerates any directory. it will be fast and idempotent.
you'll lose intermediate versions if you switch branches.
anyway, that's a sketch of my idea.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-726988458>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWLXKDHW6DPNVWQTJMDSPWB6XANCNFSM4SUYIG5A>.
|
Beta Was this translation helpful? Give feedback.
-
|
@nbriggs version mismatch: I edited my comment but you replied to the earlier version. The model in your explanation doesn't help so much with mapping it onto an old-style vcs mental model. Thus my lists of differences. I think we can make a FIXVERSIONS utility that uses the CREATED-AS of each Interlisp and compiled file to set the file modification date and its (Lisp view) version number (unix view) hard-linked If there are versions GREATER than the CREATED-AS version number, delete them. Add a git post-checkout hook to just make a 00WARNING.FIXVERSIONS file but make it a manual step. |
Beta Was this translation helpful? Give feedback.
-
|
From Larry’s message…
On Nov 13, 2020, at 11:26 AM, Larry Masinter ***@***.***> wrote:
actions (commit, push) don't just involve one file, they might affect all of the files in the repo.
I may be working on several different Lisp files/packages/facilities that are in different stages of completion and that do not have mutual dependencies. I want to share/upload/push/commit one that I am done with but not the others that are still in an intermediate state. Will the git model allow me to share just the one without sharing the others?
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, you "git add" the specific files that you want to be part of a commit, then you do the "git commit" and it records the new state of the repository (everything that is committed).
… On Nov 14, 2020, at 5:32 PM, rmkaplan ***@***.***> wrote:
From Larry’s message…
> On Nov 13, 2020, at 11:26 AM, Larry Masinter ***@***.***> wrote:
> actions (commit, push) don't just involve one file, they might affect all of the files in the repo.
I may be working on several different Lisp files/packages/facilities that are in different stages of completion and that do not have mutual dependencies. I want to share/upload/push/commit one that I am done with but not the others that are still in an intermediate state. Will the git model allow me to share just the one without sharing the others?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-727292091>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWJUBNORC3GHC42BMVTSP4VSLANCNFSM4SUYIG5A>.
|
Beta Was this translation helpful? Give feedback.
-
|
if he's making changes to existing files, isn't it the case that changes are picked up by any commit includes all existing files? |
Beta Was this translation helpful? Give feedback.
-
|
No. Unless you use the "git commit -a" it will only include files that have been staged with "git add"
… On Nov 15, 2020, at 12:06 PM, Larry Masinter ***@***.***> wrote:
if he's making changes to existing files, isn't it the case that changes are picked up by any commit includes all existing files?
I think it might be necessary to (a) work in a different branch per-project or (b) work in one branch (per user)
-- keep it updated periodically with changes to Master
-- when you want to let others see what you're doing, make a different branch (based on Master), git checkout (from your own fork or personal branch0 the files you want to release, make a new loadup if needed, test it out, then commit and push
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-727628248>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWIMCUPSSIELF7B4M7TSQAYFBANCNFSM4SUYIG5A>.
|
Beta Was this translation helpful? Give feedback.
-
|
Also -- you don't "check out files", you check out the entire repository (at a particular point in the digraph of the state). You can make a personal branch but it will contain everything, but those things will be the same as the main (master) branch, and when you're ready you commit the changed files and push that branch. If "everyone" agrees that it's good to generally release, then either you merge the whole branch into the main branch, or you cherry-pick the commit from the personal branch to be applied to the main branch.
… On Nov 15, 2020, at 12:06 PM, Larry Masinter ***@***.***> wrote:
if he's making changes to existing files, isn't it the case that changes are picked up by any commit includes all existing files?
I think it might be necessary to (a) work in a different branch per-project or (b) work in one branch (per user)
-- keep it updated periodically with changes to Master
-- when you want to let others see what you're doing, make a different branch (based on Master), git checkout (from your own fork or personal branch0 the files you want to release, make a new loadup if needed, test it out, then commit and push
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-727628248>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWIMCUPSSIELF7B4M7TSQAYFBANCNFSM4SUYIG5A>.
|
Beta Was this translation helpful? Give feedback.
-
|
i saw that git checkout can operate on individual files, but not from another branch. Let me try to spec a unix style 'fixversions' in pseudo-code along the way, fix up the file modification date/time to match This remakes the hardlinks. It should be idempotent. it mainly just trims versions which might be unsafe. |
Beta Was this translation helpful? Give feedback.
-
|
If the repository has a non-lisp versioned file (e.g. a TEDIT file or any other file with a medley version suffix), it should also be “fixed” if it is imported, getting linked to a local version 1 greater than whatever may exist locally—and preserving the previous highest local version. In that case you can’t fixed the file modification date (unless it is a file with a recognized internal time-stamp), but you can keep from overwriting local stuff.
The objective I have is that information in my local development sequence will be extended, not destroyed, when I synchonize one or more files with the repository, based on the local version-number sequencing that medley knows how to manipulate. As if I had done a copyfile from another directory and implicitly got a higher version number (coded with hardlinks and tildes etc.).
… On Nov 15, 2020, at 1:47 PM, Larry Masinter ***@***.***> wrote:
i saw that git checkout can operate on individual files, but not from another branch.
Let me try to spec a unix style 'fixversions' in pseudo-code
if no parameters, call fixversions on every file in the repo (exclude .* and *~ )
if $1 is a directory or contains a *, fixversions of every file that matches
if $1 isn't a lisp file or a compiled file, leave versions alone (? or remove them?)
for each version vers matching $1.~*~
if the file + extension name in vers doesn't match
OR the version number of vers is greater than or equal o the version number of
the filecreated name in $1
THEN delete vers
make a new hardlink from $1 to $1.~NN~
along the way, fix up the file modification date/time to match
somewhere (when enumerating directories) delete all versioned files that don't have a corresponding unversioned file.
This remakes the hardlinks. It should be idempotent. it mainly just trims versions which might be unsafe.
I think you can recreate the version history of the current branch for a single file by running git checkout or reset and then fixversions
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-727642388>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMBSJFQYDLDA72T733SQBD6FANCNFSM4SUYIG5A>.
|
Beta Was this translation helpful? Give feedback.
-
|
On Nov 15, 2020, at 2:14 PM, rmkaplan ***@***.***> wrote:
If the repository has a non-lisp versioned file (e.g. a TEDIT file or any other file with a medley version suffix), it should also be “fixed” if it is imported
what do you mean by "imported" in this context?
, getting linked to a local version 1 greater than whatever may exist locally—and preserving the previous highest local version. In that case you can’t fixed the file modification date (unless it is a file with a recognized internal time-stamp), but you can keep from overwriting local stuff.
The objective I have is that information in my local development sequence will be extended, not destroyed, when I synchonize one or more files with the repository, based on the local version-number sequencing that medley knows how to manipulate. As if I had done a copyfile from another directory and implicitly got a higher version number (coded with hardlinks and tildes etc.).
I don't think that you can get this effect. If you "git pull" a version of the repository and it contains files that have been modified that you have also modified it will tell you you can't do that because it would overwrite a file with the same name.
You can do "git help hooks" to see the points where we can get control.
> On Nov 15, 2020, at 1:47 PM, Larry Masinter ***@***.***> wrote:
>
>
> i saw that git checkout can operate on individual files, but not from another branch.
You can "git checkout <commit id> -- path/to/file
and it will retrieve the version associated with the commit, and it will show up as "modified" in your current status.
If the file "path/to/file" was modified doing this git checkout will overwrite the modified file. You can get back to the last committed state with "git reset HEAD path/to/file", but uncommitted modifications are lost. You can "git stash" to save and undo all local changes, and then reapply them after you've tried something, but it gets pretty messy.
… >
> Let me try to spec a unix style 'fixversions' in pseudo-code
>
> if no parameters, call fixversions on every file in the repo (exclude .* and *~ )
> if $1 is a directory or contains a *, fixversions of every file that matches
> if $1 isn't a lisp file or a compiled file, leave versions alone (? or remove them?)
> for each version vers matching $1.~*~
> if the file + extension name in vers doesn't match
> OR the version number of vers is greater than or equal o the version number of
> the filecreated name in $1
> THEN delete vers
> make a new hardlink from $1 to $1.~NN~
>
> along the way, fix up the file modification date/time to match
> somewhere (when enumerating directories) delete all versioned files that don't have a corresponding unversioned file.
>
> This remakes the hardlinks. It should be idempotent. it mainly just trims versions which might be unsafe.
> I think you can recreate the version history of the current branch for a single file by running git checkout or reset and then fixversions
>
>
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-727642388>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMBSJFQYDLDA72T733SQBD6FANCNFSM4SUYIG5A>.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/49#issuecomment-727646049>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWJSU5S5CH26MCR5ZP3SQBHFNANCNFSM4SUYIG5A>.
|
Beta Was this translation helpful? Give feedback.
-
there are still some things not settled:
file.~23~versions ae checked in) -- Issue how to use git to emulate Interlisp-style versioned file system #17issue change Lisp source & compiled file names in github to lower case #15
change eol from cr to lf -- Issue Changing the EOL of Interlisp source files to LF #12
@rmkaplan
@nbriggs
Beta Was this translation helpful? Give feedback.
All reactions