Re:Mercurial with Largefiles: Why it is not a solution for g...
by kevincox on Sunday December 03, 2017 @04:49PM
(#15839803)
Not explicitly, IFAIK the main slowness/limits you risk hitting are:
1. Git clones are deep and wide by default, so you end up with local repos that are the size of the total history. (easy to work around)
2. Git narrow clone support isn't the greatest, so you will probably want to fit the "working directory" on one computer. (somewhat painful to work around)
3. Git has to checkout all files every time you change branches which can be slow if you have a large working directory. (very painful)
4. Many operations (status, diff, commit for example) require git to scan the working directory to see what changed. This will be very slow if you have many files in your working directory. (very painful)
Luckily all of these problems can be solved seamlessly with a virtual filesystem approach. For example https://github.com/Microsoft/GVFS
1. Git clones are deep and wide by default, so you end up with local repos that are the size of the total history. (easy to work around)
2. Git narrow clone support isn't the greatest, so you will probably want to fit the "working directory" on one computer. (somewhat painful to work around)
3. Git has to checkout all files every time you change branches which can be slow if you have a large working directory. (very painful)
4. Many operations (status, diff, commit for example) require git to scan the working directory to see what changed. This will be very slow if you have many files in your working directory. (very painful)
Luckily all of these problems can be solved seamlessly with a virtual filesystem approach. For example https://github.com/Microsoft/GVFS