Image Assets and Repo Management

[benloh]

In GitLab by @benloh on Jul 12, 2021, 10:15

[benloh]

In GitLab by @daveseah on Jul 27, 2021, 10:03

Beginning !121

[benloh]

In GitLab by @daveseah on Aug 2, 2021, 10:55

There was an incident with a bad merge today, though I am not clear on the details of what the merge itself contained or how it happened. From what I can glean:

• a change was made in a branch of a local repo with origin on gitlab
• this local repo merged another branch causing a merge conflict
• the merge conflict was not resolved
• the conflicted branch was pushed back to origin
• the merge conflict was also detected in another unexpected branch

Corey suggests that we divide our main repo so data that is subject to change (i.e. activity scripts) be located in a git submodule, which is a "repo inside of a repo"; that way the histories are kept distinct and perhaps helps prevent bad merges from affecting the working codebase.

There are some pros and cons to this:

• PRO: Isolation of some data from the rest of the repo, theoretically making it less prone to bad merges taking down the codebase. In practice, though, I am not sure this will be a robust protection because bad merges can still happen, except now in two possible places

• CON: If there is any kind of dependency on data stability (names, certain files) in the subrepo for it to work with the parent repo, this increases the version tracking burden. For example, if there is a change in the parent repo that necessitate a change in the subrepo, you have to update both of them and the history is not tied together. You have to update two change logs too. It is for this reason that we switched to MONOREPO for the core repository organization, which contains multiple packages. It seems more desirable to have stable history (something we rely on all the time) than to protect against bad merges (these are rare by comparison).

• OBSOLETE CON? In the past, submodules had to be initialized separately from their parent repo, requiring some git command line stuff we didn't want to inflict on non-technical grad students who had to pull the repo and set it up. I think these days submodules can be cleanly initialized at the same time without these extra commands; will have to look into it to be sure.

• PRO: Having researcher archive as a submodule gives us more flexibility in granting access to different parts of the system, and potentially keep the rate of repo size growth down if there are a lot of changes.

Bumping up a level, the core desire is to have some way of keeping researcher-authored script content version-controlled in some way so if something blows up there, it doesn't blow up the codebase.

[benloh]

In GitLab by @daveseah on Aug 9, 2021, 12:41

up to august 8, 2021

[benloh]

In GitLab by @daveseah on Aug 9, 2021, 12:41

added 36h of time spent