When coding software / running models / creating extensive configurations, your code space / project folder / configurations will most likely contain a mix of text files, data files and software binaries. All these files need to be place in a repository under version control and need to be managed as a whole. For the text files you will want to be able to compare differences between versions, in order to understand what has changed over time. This will not be the case for binary files or very large data files as humans are generally not well equipped to compare bits and bytes.
In the 'past' SVN was an ideal place to store your whole repository in one place. Currently SVN is in the process of being phased out and as a replacement GITLABhas been introduced. What the advantages / disadvantages of both systems are will not be discussed here. Instead we will focus on how to setup your GITHUB repository to include both your text based files as your larger binaries.
The problem with GIT (and therefor also GITLAB) is that it is not designed to handle large and or binary files. To overcome this problem GIT Large File Storage (LFS) was introduced. The basic idea behind GIT LFS is that the actual binary file is not stored in your GITLAB repository. Instead only a reference to this file is stored. The actual binary file is stored in an Object Storage location (S3 bucket).
GITLAB offers LFS out-of-the-box, using the MinIO server hosted by Deltares .
So in short. You will have a GIT repository in the Deltares GITLAB instance which will contain only your text base files and small data files. While your large files or binary files will be stored on the Deltares Minio server.
To manage all your text-, large- and binary files as a single project you have three options to connect your GITHUB repository to the Deltares MinIO object store:
Prerequisite: In the below guides we expect the user to have a basic understanding of GIT and its related commands.