LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How does version control with LabVIEW VIs work?

Does anybody have experience with version control and LabVIEW? Since LabVIEW VIs are not text-based, how does it work? I would like to use git but I have a few questions:

  • When committing changes, does git recognize the differences in the VI or does it replace the whole file with the new one? Does this result in a large expansion of the repository?

  • Is there a possibility to merge different versions of a VI?

  • Or is there a version control that works better for LabVIEW?

Message 1 of 16
(10,191 Views)

Hi Reccay,

 

When committing changes, does git recognize the differences in the VI or does it replace the whole file with the new one? Does this result in a large expansion of the repository?

SCC system recognize VIs (and other LabVIEW files like CTLs or FPGA bitfiles) as "binary" files. Only differences are (usually) stored…

 

Is there a possibility to merge different versions of a VI?

I needed such a feature very, VERY seldom. Most often you are fine with getting back older revisions…

 

Or is there a version control that works better for LabVIEW?

I use TortoiseSVN since 10 years (purely on its own without any plugins for LabVIEW).

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 16
(10,187 Views)

I use Git here (either via Git for Windows (Git Bash), or the WSL and Ubuntu -> bash -> git).

My answers to your questions first:

  • As GerdW said, most files are stored as binary blobs. Although this does make the repository larger, probably quite a bit more quickly, it's not a huge problem. I've only noticed large (10s of MB) repositories when I store compiled code into the repository. From the files I've tried, I'd say this is worth doing only if it's an FPGA bitfile (because you might want an old version, and compiling takes a long time)
  • It is possible, using a tool shipped with LabVIEW (at least the professional version) - LVMerge. I don't really like the layout, and typically avoid this tool. However, LVDiff is really useful and I frequently use that. I'd recommend compiling a copy of this repository and using it to put these as tools for Git.
  • No idea. I like Git and don't have any significant problems (but also only me and one colleague, across ~5 computers, so not a large team and conflicts are relatively infrequent).

Some additional points:

  • Removing compiled code is crucial. Change this setting in your LabVIEW Preferences, your Project preferences, and then mark all the VIs as removed. A guide can be found here: Facilitating Source Control by Separating Compiled Code.
  • Several guides on using Git or other SCC with LabVIEW exist. See Delacor for some video guides (if you like those)
  • You can block Git from trying to auto-merge your class files using the .gitattributes file to forbid merges. I've had moderately good luck merging project files, and so-so with library (lvlib) files. YMMV - generally I think it's safer to avoid merging any of these files automatically. "git checkout --{ours,theirs} myLibrary.lvlib" might be a nicer option...

Good luck!


GCentral
0 Kudos
Message 3 of 16
(10,176 Views)

Actually the problem is that LabVIEW has files that are not binary.

 

.lvproj, .lvclass, .lvlib, etc. GIT will see those files as the text files that they are, and will automatically merge them. This is not what you want GIT to do...

 

See LabVIEW-and-git, and this one (same title, different name): LabVIEW-and-git

0 Kudos
Message 4 of 16
(10,147 Views)

@GerdW wrote:
[...]

Is there a possibility to merge different versions of a VI?

I needed such a feature very, VERY seldom. Most often you are fine with getting back older revisions…

[...]


I want to highlight this point. Gerds statement here is kind of final... but why does he have that opinion?

My personal statement on this point would be: Try to avoid merges. If you require them a lot, your development process is lacking and should be improved.

Please note that my statement applies to any programming language.

 

The reason for Gerd and me to share a similar opinion is that for single developers, there is simply no need to perform any merge as you are the only one to work on the project. In turn: If you encounter a situation where you want to add stuff... simply do it and create a new version by doing so. If you find the change to be bad, simply revert to the old version (as Gerd points out).

If you want to evaluate different approaches: Create two branches. Continue to develop on one of them once evaluation is done and abandon the other branch.

 

If you work on a team, you can encounter situations where two developer share the same code to implement different stuff. In that case, a merge CAN be useful. However, running into that situation indicates bad project management or bad project design. Or in other words: Your development process is poorly defined and should be improved or you have to redo the whole project design.

 

For the very rare incidence where you need merge: LV has its own Diff and Merge tools you can configure per file type in most SCC providers....

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 5 of 16
(10,134 Views)

LabVIEW SCC on youtube (playlist): https://www.youtube.com/playlist?list=PLZ3A_SIOKdQvUnA5U7Vuz-teKbcVcTnk4

 

NI resource: http://www.ni.com/product-documentation/4114/en/

 

We are using SVN/tortoise for many years and are moving to bitbucket/sourcetree mainly due to the decentralized aspect.

 


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
0 Kudos
Message 6 of 16
(10,116 Views)

@Norbert_B wrote:

@GerdW wrote:
[...]

Is there a possibility to merge different versions of a VI?

I needed such a feature very, VERY seldom. Most often you are fine with getting back older revisions…

[...]


I want to highlight this point. Gerds statement here is kind of final... but why does he have that opinion?

My personal statement on this point would be: Try to avoid merges. If you require them a lot, your development process is lacking and should be improved.

Please note that my statement applies to any programming language.


That doesn't contradict, in fact, it's almost the same statement. GerdW probably learned how to avoid merges, and therefore seldom needs it.

 

It is definitely something to avoid (in every language), even though I used it a few times successfully. That is, manually merge, item by item. I do want control.

 

 

0 Kudos
Message 7 of 16
(10,105 Views)

I'm solidly in the TortoiseSVN, largely-single-user-or-small-team camp (and have been using TSVN "stand-alone" with LabVIEW for >10 years).  I only recently started setting up Projects with "remove Compiled code", which speeds up and "slims down" the Commits and Updates, so is probably a "good thing".

 

When I started, I made some Branches, then found I was really "making a mess", so stopped using them for about 8 years.  Only recently have I timidly ventured back.  Subversion "merging" isn't pretty -- I usually do it "manually".

 

When I forget to Update and inadvertently create two versions that need to be "compared" and "reconciled", I use LabVIEW's Compare tool and do it "by hand".  I've written a utility for myself that will look at two versions of a Project (say two Revisions from my Repository) and will generate four lists for me:  the files that are Unique to Folder 1, Unique to Folder 2, the Same to LabVIEW with the Compare Options I choose, and the ones that are Different, and gives me the opportunity to "Show Differences" for the latter -- I make notes here and then know which VIs to "manually merge" (it usually is very simple -- "Use Folder 1's Version" or "Use Folder 2's Version").

 

We recently got a local Git Server (we aren't supposed to use outside Repositories), so I looked into using Git for LabVIEW.  Decided not to abandon Subversion, which seems more appropriate for my LabVIEW use.

 

Bob Schor

Message 8 of 16
(10,089 Views)

While branching isn't really necessary if you're the only one developing, it comes in handy when developing with a team.  Sometimes you can't help but be working in a closely related area of the code and can't afford to break their code while you poke around and make your changes (which may or may not work).  I commit incomplete work all the time; no one sees it until i'm ready to show it.  This requires vigilant sync merging to your branch to catch anyone's commits to the trunk (and accommodate any changes they have made).  While it seems to be a huge waste of resources, most (all?) versioning software just keeps track of what is different.  When you "create" a branch, you're just creating a new pointer to what the files looked like at the moment you created it.  You're not creating new files.  It just looks like new files in the GUI so humans can keep their sanity.

 

That being said, it's never a good idea to have multiple devs working in the same LabVIEW project!

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 16
(10,081 Views)

Branching is useful for single developers.

 

If the customer askes for a bug fix on an old release for instance. That release should be branched, and the bug should be fixed in the branch. The release should have been tagged, in that case the tag can be converted to a branch.

Message 10 of 16
(10,078 Views)