07-02-2019 08:41 AM
Anyone having to use GIt LFS to handle LabVIEW source within a git repo? If you have used any issues seen?
"lots of large files and/or binary files will eventually slow down Git, which using Git LFS would alleviate."
07-02-2019 12:09 PM
+1
I'm also interested in hearing any experience with the LFS plug-in.
07-16-2019 10:26 AM
@tider06
We are currently looking into this. Sumedha, of the LabVIEW NXG Product Owners, will post a reply when she has enough information.
07-17-2019 11:33 AM
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
07-17-2019 12:32 PM
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.
DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (Developer Experience that makes you smile )
07-22-2019 04:02 AM
@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.
09-30-2019 01:42 AM
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).
09-30-2019 04:23 PM
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?
09-30-2019 04:43 PM
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?
09-30-2019 09:32 PM
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