SCM systems organize the files placed under configuration management in a tree structure, which always stores the changes from the previous version. If a specific revision of a file is requested, Git compiles the correct version from the existing deltas and delivers it. This mechanism allows the size of the source code repository to be kept very compact, since the entire file is not saved each time. Unfortunately, this technique only works with pure ASCII text files, as is the case with simple source code. However, if binary files such as Office documents, images, or compiled libraries are stored in the repository, this mechanism does not work. Every change to the binary file represents a new version and is completely incorporated into the repository. If you have a large number of such binary artifacts that are also frequently modified, disk space consumption increases quite quickly.
Another very negative effect that occurs over time is the comparatively long time it takes to check out even small subdirectories. Times of over 15 minutes are quite possible in some projects. This is because Git needs more time to create the tree of the requested revision due to the large number of files. This is also the basis for the principle of not including binary files in version control if possible.
The problem just described is addressed by the Git Large File Support (LFS) plugin. After determining which files are to be managed via LFS, they are stored separately and linked to the repository via a reference.
Leave a Reply
You must be logged in to post a comment.