Git LFS

[Taggart]

The answer to number 2 is not locking files, but more modular design.  Not only will it solve that problem, but will probably solve other problems for you as well.

There are plenty of advantages to git. Most notably it is much easier to branch - although to take advantage of that in LabVIEW you need a more modular design.

What do I mean by modular - break your program into a bunch of libraries (or classes) where each one has one and only one very specific purpose. You should be able to describe what it does in a single sentence without using the word and. (look up coupling and cohesion).

if you do that well and only one person works on one module at a time, you should rarely if ever have to merge, as in I haven't had to merge in years.

And as to #1, not sure how large your repository is, but I haven't noticed any issues.  If you have really large vis, modularity will help with that. You may have more vis but on the whole they will be much smaller. Also make sure you don't have default values for graphs, arrays, etc.  They chew up disk space.  

[manig]

Thanks, Taggart for the response. It makes sense.

I just got to know git also allows us to clone a single branch and that can be used if users need not require the whole history in the local repo.

[joerg.hampel]

I agree with Sam. While locking is definitely convenient, I think it defies the purpose/benefit of a decentralized SCC system. We use gitflow to work around the need for locking.

@Chris, there are different sorts of large assets, with build results probably the most frequent ones. We also have shared libraries or sometimes large binaries in the documentation. Seeing as we try to contain as many dependencies as possible in our repos (as opposed to vi.lib or user.lib), that might add to my perception.

To add to the last comment, here's a short description of how to clone only a number of commits of a git repo in order to save on bandwidth and local storage.

[Taggart]

Great link Joerg!  Thanks for pointing that out.