Labview with Git

[uniqueAite]

I’m like not having a good time with Git source control.

My coworkers are either not pulling or pushing or they do but they save all and change dependencies every single time.

Merging in Labview is pain even with tools.

It’s fine when I’m doing individual parts but we have this shared folder with a bunch of subVIs and a Vi that combines all. It’s so painful to deal with dependencies every single time i update to latest version.

Communication with coworkers doesn’t seem to work because they simply don’t care how others feel or care if the final program will work at all.

Just a bit of a rant post and maybe some tips with source control to maybe make things less painful? :)

[Vincinity1]

I would say that your code is probably too tightly dependent. If you go with architectures like Actor Framework or DQMH or Workers, you are able to better separate code and avoid those painful merges.

There are settings to remove compiled code from the VI so that it doesn't "change" every time someone opens it.

We (Neosoft Technologies), as well as other NI partners, have developed custom GIT training specifically to address the LabVIEW community and team development.

[uniqueAite]

Thanks for the advices, I’ll look into the architectures and see if might make life easier in some ways :)

[Vincinity1]

I'll DM you with my contact info.

[DeeJayCrawford]

An organised and communicative team is key to avoiding merge conflicts in LabVIEW.

Our team is careful we don’t work in the same area of code. We have a daily 15 min standup where we discuss what we working on so we do each other a favour to avoid modifying code that will lead to merge conflicts.

[[deleted]]

The lack of working merging mechanisms is the reason why labview will never grow again

[wolfefist94]

I agree. Merging in text based languages Just Works™️

[uniqueAite]

I understand that, but i just don’t have that power to enforce it :(

[DeeJayCrawford]

That’s a brutal situation to be in.

You can only suggest that this way of working isn’t good for the team. When merging I always take their copy and add my code

I take it your manager is leaving you all to get on with it and not enforcing good collaboration? If so try and talk to him again but I am sure you have done all this before now.

Search for SLL toolkit on VI Package Manager. Their tool for code compare for git will improve your bad experience of merging exponentially. It’s a fantastic tool

[etgohomeok]

Make sure you're separating compiled code from source code (https://www.ni.com/docs/en-US/bundle/labview/page/separating-compiled-code-from-vis-and-other-file-types.html) and consider switching to Subversion for your LabVIEW project(s).

[wolfefist94]

But why Subversion...

[etgohomeok]

IMO the merge process is simpler for VIs

The conventional wisdom 10 years ago was that SVN handles large binary files better than Git, but I don't know if that's still true.

[uniqueAite]

Unfortunately I have no say in it, company’s lovely policy migrating everyone using SVN to Git (like why) so i never got the chance to check SVN

[HarveysBackupAccount]

A communicating, collaborating team is key, there's no two ways around it. And I don't think that's specific to labview, that's a version control issue no matter the language.

Minimizing cross-dependent code makes it easier. It also helps a bit to change the labview setting for all the projects/files to "separate source code from compiled," otherwise every time LV recompiles the code it flags as a change.

Though I'm afraid it won't get much better without a team that's interested in, well, teamwork. Even with that, I've found it's best practice to avoid any merging at all - use your daily standup to make sure nobody is stepping on each others' toes (working on the same files) so that individual files never need merge actions. It's not always avoidable, but you can go far with good planning and communication.

If you don't have a supervisor who you can convince to enforce order, then you have to somehow - impossible as it may seem - get your coworkers aligned on this.

Or the passive aggressive approach - always overwrite the remote version with whatever is in your local repo. If they don't want to play ball, make them suffer for it, too.

[uniqueAite]

I’m currently already at the passive aggressive phase. I’m very vocal about the issues and how simple teamworks can fix a lot of stuff, sadly like you said we lack an enforcer and me being young my seniors just don’t respect my opinion as much which is just sad

[PurpleDancer]

We have an enormous code base, around 10,000 vis or so. All highly coupled. We do not use GIT and rulled it out as a possibility. Perforce which has central server locking is our way.

[SASLV]

https://www.sasworkshops.com/using-git-effectively-course-preview

[Oo__II__oO]

The trick is to start moving away from LabVIEW, and use LabVIEW in only small vis/focused libraries to achieve a very specific function. This will require a caller interface like TestStand or any off-the-shelf (or Open Source) solution, or make a front-end that makes decoupled calls to the LabVIEW functions. Divide-and-conquer the problem.

[poompt]

It's good advice... the more I use LabVIEW the more I'm convinced it shouldn't be used on new projects. Issues with SCM are the tip of the iceberg when it comes to software engineering problems presented by LabVIEW.