Suggestion for -preloaded

[DavinChurch]

When using the -preloaded switch, how about allowing it to have an argument to indicate that the workspace is partially preloaded. If, for example, the workspace was saved as of 1/1/2025 you could tell -preloaded to only ignore files that were saved prior to that date. You might use -preloaded=1/1/2025 to indicate this, for instance. But if a few of the files had been last changed since that date, then it would load those files normally.

Another syntax might be -preloaded=* which could indicate using the loaded workspace's own timestamp as the cutoff date, rather than a specific date, and only files changed since the workspace was saved would be loaded as new/changed while the bulk of them would be considered as unchanged from the saved copy of the workspace.

[mkromberg]

Yes - I've already been thinking that we should incorporate some of the recent build code we have written for applications into Link itself.

[aplteam]

But use internation date format: -preloaded=2025-01-01

[DavinChurch]

Agreed - I wasn't sure which format would be best, since there are so many possibilities. This might be extended to optionally include a time-of-day and/or TZ, too.

[mkromberg]

... but the 99% use case is going to be a reference to a workspace, shared code file, or other artefact that has been preloaded - plus a source folder or folders.

[DavinChurch]

True enough, but I can see the possibility of re-saving the workspace (or just touching the timestamp) for some other reason without actually updating any source code, and for that the file time wouldn't be reliable. I figure it wouldn't require much effort to allow a hard-coded date in case a file date isn't good enough.

[mkromberg]

Yup, I can see that. For a while, I experimented with running of git status, but that doesn't include untracked (i.e. new) files and caused all kinds of trouble. File timestamps are more reliable - except of course you cannot see deleted files. But that is VERY rarely a problem.