maltem-za
commented
1 year ago Most changes outlined above have now been released with 7.0.0 - the page What’s New and Changed in CATMA 7 summarizes the impacts on synchronization and roles & permissions, while the page Upcoming Changes to the Backend Storage Mechanisms and Data Structures was created for those who work with raw CATMA data.
Notes on some of the above points:
- CATMA will show the fact that there is an open merge request to the master present.
- Not implemented - currently we try to merge any open MRs when synchronizing
- Maintainers get notified when a merge request to the master has been made.
- Probably depends on notification settings within GitLab, not yet tested (also see #237)
- Commits are executed after each heavy operation (altering a Tagset, semi automatic annotation), after logical steps like closing an Annotate tab or switching to another writable Collection, after closing a session
and after a certain amount of time of inactivity.- Last part with strikethrough not implemented
- An overview of commits in the master which are not present in the dedicated branch shows what could be intergrated.
- Not implemented (also see #183, #184 and #224)
- On request changes to the master can be merged into the dedicated branch locally via CATMA if the merge can be done conflict free. Otherwise local changes need first pushed to remote and merged via a merge request into master.
- When synchronizing, if the dedicated user branch has any commits that are not present in master we try to merge them in via MR, subsequently we try to merge master into the dedicated user branch locally
- The mail system of the Gitlab backend will be used to notify users of things happening in the backend.
- See 2nd point above, we may also need to review the current mailbox / SMTP setup as it's not intended for high mail volumes
- The file and folder layout will remain the same for now (see Optimized directory and file layout for Collections #304 ).
- The high-level layout has stayed the same, however note the changes made to how annotations are stored (details in linked issue)
- Each resource can be assigned to a responsable user. Change operation by others will result in a warning. Collections with a responsable user that is not the current users are filtered out by default.
- Responsibility is assigned to resource creators by default and there is currently no way to change it through the UI. Collections are filtered in the Annotate module by default, but not in the Project module.
- Automatic Collection creation on joining a Project will be done in the joining user's namespace and no longer in the inviting user's namespace as it is now.
- Not implemented, currently there is no automatic collection creation
Copying resources between projects (replacement for forking) has not been implemented, except for some foundational aspects.
The CATMA Project structure as a Gitlab group with one git project per resource and their integration via git submodules and a git container project has proven to be a major performance bottleneck. This structure leads to a high number of git projects that need to be considered when working with one CATMA project and neither Gitlab nor git submodules seem to be optimized for the required workflows and such numbers.
The reasons for choosing this structure had been
The goal is therefore to change the CATMA Project structure to a single git project with the resources as ordinary folders. This single git project will then be responsable for the orchestration of resources making the use of git submodules obsolete.
This way we will loose the per resource Gitlab permissions. To compensate that we will embrace Gitlab features on branches, i. e. protected branches, branch push permissions and merge requests and we will introduce an optional weak ownership of resources:
Forks haven't been used much since they were introduced in CATMA 6 and especially the ability to merge changes back into the parent of a fork has never been used. Copying over Tagsets, Collections and Documents from one CATMA Project to another will still be important but it can't and won't be based on a Gitlab fork with our new approach sketched out above. Instead this will be implemented with a simple copy with a fresh history. The HEAD commit hash and the name of the source git repository will be recorded in the meta data of the resulting new resource in the target git repository.