Git LFS

[tider06]

Anyone having to use GIt LFS to handle LabVIEW source within a git repo?  If you have used any issues seen?

https://git-lfs.github.com/

"lots of large files and/or binary files will eventually slow down Git, which using Git LFS would alleviate."

[A.E.M]

+1

I'm also interested in hearing any experience with the LFS plug-in. 

[EricR]

@tider06

We are currently looking into this.  Sumedha, of the LabVIEW NXG Product Owners, will post a reply when she has enough information.

[Sumedha]

Hi @tider06,

Whether you should use Git LFS or not is dependent on the types of files in your repo, how often your make changes to certain types of files, the file sizes, etc. So, I don't have a concrete "use LFS or not" recommendation to give. But I would like to share some internal analysis that some of our R&D teams did to evaluate whether to use Git LFS for some of our projects and the pros/ cons of using it.  The summary is we decided to not use it for our repo. Please find our analysis attached.

This is simply our analysis for our specific repo and team, and not a general statement for or against Git LFS.  If you end up doing a similar analysis, I would be interested in seeing the results as that would help us refine our understanding further. 

Hope this helps!

Sumedha

[joerg.hampel]

One of our customers enabled LFS a few months ago. The repos are hosted on a local GitLab system.

We did have some problems initially (something on the serverside related to the LFS option would actually break pulling code), but since their IT department solved this, there is no tangible impact for us as users (i.e. "everything works well").

It is too short, still, to evaluate the impact on the server side.

[benjamin-hinrichs]

@Sumedha Thanks for the very interesting report. I'd like to add to your analysis that on the server side, large repositories use a lot of server ressources. So if you're working with hundreds or thousands of concurrent users, ressource usage quickly becomes a bottleneck.

I'll use the 500kB rule of thumb in the future. It seems like a good guideline.

[manig]

Thanks, Sumedha for sharing the report, it gives me a good understanding of the LFS internals. Please let us know if your team has evaluated the File Lock option from LFS (I understand the lock can be worked around by having a good architecture, workflow and assigning owners, but still the lock would be useful to avoid unexpected conflicts).

[cirrusio]

I am curious - if you are using Git LFS - what is the use case?  Are people here generally using large assets that change frequently and those changes need to be tracked?

manig - why would the file lock option be useful?

[D_Hooks]

I would think that one of the most obvious use case for Git LFS would be storing the build output from your LabVIEW project.  So, all of your source VIs, classes, libraries, projects, etc are in your normal Git repo, while PPLs, EXEs or installers are stored using LFS.  You wouldn't want those large binary files making your repo enormous, and using LFS would allow you to store and track the large binary files without needing a secondary storage system.  Is anyone using Git LFS in this manner?

[manig]

Thanks cirrusio for the reply. We are trying to move from SVN to git and wanted to evaluate the pros and cons.

Cons we noticed with regular git are, ( please correct me if I am missing something)

1. Requires more memory in local repo as it downloads all the revision history.(assuming VIs have a compression ratio of 50%, felt LFS would be efficient).

2. No file lock option as in  comSVN. As compare and merge are not very effective in LV and to avoid any conflict it is better lock it before making any changes.

Please let me know your thoughts.

Thanks,

Mani