Skip to content

Git issues from svn perspective

Jump to bottom
Dietmar Winkler edited this page Feb 29, 2020 · 5 revisions

Note

In the development of the MSL we don't actually rely on any code-locking. This is simply not necessary. Same goes for binary files as we don't handle huge binary files as part of the MSL. So please keep this in mind when reading the information below.
 (Dietmar Winkler, 2020-02-29)

When changing from svn to git/github there are some important features of svn that are no longer (directly) available in git/github. Find below such a list and also suggestions how to fix the issues:

  1. Files cannot be locked in git/github (-> use git-lfs)
    When making a large restructuring of a repository or when accessing binary files (such as a Word document), it is standard in svn to lock the corresponding files or directories beforehand. As a result, when making "update", users get read-only versions of the file (so they notice that they cannot modify the file until the lock is released). Since git is a distributed version management system, there is no "lock" feature, because there is no central repository. Also github does not support this as an addon.
    This can be fixed by using git-lfs (git Large File System), see below.

  2. Binary files cannot be practically handled in git (-> use git-lfs)
    Git is a distributed version control system. Therefore, a user has a local copy of a complete repository, including all branches and the whole history. When storing a binary file, such as a Word document, git cannot compress much, and therefore every commit basically stores another copy of the binary file. This is essentially the same situation as with Subversion (try to avoid binary files, i.e. use Markup-documents in .md format instead of Word-docx files for simple meeting protocols, which GitHub can show and format directly) If binary files are large, the local memory consumption and the "push"-time can become excessive.
    This can be fixed by using git-lfs (git Large File System), see below.

  3. Holding several branches in the file system (-> use multiple clones or multiple worktrees)
    Sometimes one has to merge branches manually together. In svn it is usual in this case to "checkout" or "export" the different branches into different locations of the file system, and then perform the merge. In a git repository, normally only one working tree of one of the branches is available in the file system at a time (selected via git checkout, or e.g. "Switch ..." in GUI tools). This working tree is called the main working tree.

    If two or more working trees of different branches are needed in the file system at the same time, this is done through linked working trees, which are working trees residing outside of the main working tree/repository, but linked to the same local repository. Linked working trees are added via the git worktree add command.

    If working with GUI clients that do not (fully) support linked working trees, an alternative is to clone the local (or remote) repository into a second repository, which of course has a second main working tree. It is not unusual to work with multiple local clones of a remote repository, in order to work on seperate branches at the same time, etc.

    If one only needs access to the files, e.g. for manual diffing, etc., then one can also use the git archive command (or related GUI commands, like Export/Archive...) to export a branch as a ZIP archive locally.

    Another way to do the latter (though redownloading from GitHub) is to click on the "Clone or download" button in github, select "Download ZIP", and store the current version of the seleted branch on the desired location in the file system.

As mentioned above, git-lfs solves the problem of large files, especially of binary files in github. Basically, git-lfs turns git from a distributed version management system to a version management system with central repositories for selected file types. This means that for the selected file types, the files are physically stored in one location (for example in github) and in the working copy (selected via "Switch ..."), but not in the local repository of the user (containing all branches and history). In the latter case, only the path names of the files are stored, but not the files itself. Since there is now a central repository again (for the selected file types), it is also possible to lock these files, as in svn. A good description and tutorial of git-lfs is here. So, to summarize, think of git-lfs as svn for selected file types.

Git-lfs is a separate software that is used on a command line. Starting with version 2.13.0, it is included in Git for Windows, so does not need to be installed separately. It might not yet be supported by all GUI clients for git (e.g. it is not yet supported by TortoiseGit). It is, however, supported by Sourcetree.

Clone this wiki locally