Configuring Hg or Git to use LabVIEW Compare and LabVIEW Merge


I gave a presentation during NI LabVIEW Developer Days at Austin, TX. I prepared this presentation for Dev Days and it was presented at other locations in the world, too.

[edit March 8, 2018] This video was also used for a webinar at NI. Unfortunately, the chat section is not included with the webinar video.

Click to expand chat from webinar

Sorry, the very beginning of the chat was lost 🙁

Vadim Bodner: your collegue wants to work on a data storage

Vadim Bodner: see how sharing a folder for this can cause issues? 

Matthias BAUDOT: SCC is a solution used by all developer teams in the world in all companies 

Erik Ledding: Sorry – Source Code Control 

Matthias BAUDOT: there are multiple tools for SCC: Git, SVN, Perforce, Mercurial are examples 

Matthias BAUDOT: they are from different software companies 

Fabiola De la Cueva: Tools for Source Code Control or Version Control: are the ones mentioned by Matthias plus others like TFS, ClearCase 

Fabiola De la Cueva: The free ones are SVN, Git, Hg 

Erik Ledding: And some SCC are open source if cost is a concern

Fabiola De la Cueva: Perforce up to two users is free

Vadim Bodner: or your colleague accidntly changed a part of the code you just got working and no longer sure what she/he had done

Scott Doyle: Clicked on the previous link on how to configure Hg or Git for LV – I think that is exactly what I was looking for Fab 

Michael Grant: @Matthias BAUDOT: So SCC is not a software, but more so a category? I’m a single developper here at our company, and I haven’t implemented anything beyond Rev savings

Vadim Bodner: byt the way, Fabioal and other women here, happy international women’s day!

Fabiola De la Cueva: This video is showing two separate developers working using Mercurial (hg)

Jorge Luis Orta: Whats the best interface for GIT

Casey May: @Jorge SourceTree

Jorge Luis Orta: i am not a fan of the command promt

Erik Ledding: Whew – the exact tool we use.

Fabiola De la Cueva: @Jorge, you can use SourceTree or TortoiseGit

Matthias BAUDOT: @Michael Grant correct, SCC is more a way of working. You should use SCC even as a single developer

Hansel Neurath: There is a set of SCC programs that can be used via the LabVOEW project window.  Does anyone know if GIT has been included in this support list by NI yet?

Fabiola De la Cueva: @Scott Doyle, glad the first blog post helped you with the different set ups, it is a little outdated, let me know through the blog post comments if you have any questions.

john orourke: We use Sourcetree.   I like it alot.  Better that TortiseSVN

Fabiola De la Cueva: @Hansel, NI no longer provides support for new SCC tools, the community does

Fabiola De la Cueva: ViewPoint has a TortoiseSVN tool via the tools network

Matthias BAUDOT: There is a tools called Git4G on the LV Tools Network that allows you to push commit and pull from your LV Project

Matthias BAUDOT: but it is not supported by NY

Fabiola De la Cueva: I know that others are working on tools to integrate with LabVIEW for Git or Hg

Matthias BAUDOT: NI

Boyd Crow 2: I think we don’t need 15 minutes of convincing followed by examples at breakneck speed.  I came in convinced.

Jorge Luis Orta: do you have a list of git ignore files

Michael Grant: Sorry to sound like a total newbie to SCC, but is there a SCC solution that’s opensource that doesn’t chew up much system resources on a Linux (Ubuntu) system? My second PC that I use for CFD has a RAID 0 of 32 TB that I can keep data on and have access to over the network

Jorge Luis Orta: or which files do we ignore

Fabiola De la Cueva: @Boyd Crow 2, there are different levels of proficiency, as you can see even here, there are a lot of people who do not even know what SCC is

Michael Rodriguez: Is tortoiseHg the preferred front end for Hg on Windows?

Fabiola De la Cueva: let me know what other topics you would like to review and maybe in the future we can present about that. Also, this video is available for you to pause and play at a lower speed if you want:

Casey May: @Jorge You can choose to ignore whatever you like, but I choose to ignore my builds folder and the LV aliases files, for example

Michael Grant: @Fabiola De la Cueva & @Boyd Crow: I’m one of those that’s starting at zero when it comes to SCC

Fabiola De la Cueva: @Jorge Luis Orta, let me look for the link on GitHub, they have a good setup for LabVIEW ignore files

Matthias BAUDOT: @Michael Rodriguez I like SOurceTree too

Vadim Bodner: Fabiola, when you so called take a peak

Matthias BAUDOT: SourceTree works both for HG and GIT

Vadim Bodner: you don’t overwrite where you are currently at

Fabiola De la Cueva: list of ignore files:

Boyd Crow 2: I have been using Mercurial for years and this presentation is WAY too fast to follow.

Stephen Swindley: So on that example, the graph shows the main repository and the local repository?

Michael Silverstein:  agree – too FAST

James Wharrie: Agree with Boyd,

Tim Cormier: Agree – too fast

Fabiola De la Cueva: @Vadim Bodner, exactly, you get to take a peak, to get a preview of what your peer did

Adam Gotway: Is there any hope to fix the LV compare tool to not break all the sub VIs when performing a GIT diff? The diffed VIs are always opened in a temp folder and then can’t locate the sub VIs.

Vadim Bodner: Fabiola De la Cueva: @Vadim Bodner, exactly, you get to take a peak, to get a preview of what your peer did – so this does not overwrite your non-committed progress?

Fabiola De la Cueva: @Boyd Crow 2, I guess you didn’t know me 😉 Sorry, I am fast. This is why I use videos, so you can slow me down later. Sorry!

Boyd Crow 2: Explain how I slow down a video later.

Justin Thompto: LabVIEW with parent and child classes makes source control even harder when the parent and child are all in the same repository and share the same projet

Matthias BAUDOT: @Adam Gotway I dont think so, but the goal when doing a diff is to see the differences, not to run the code, so I dont see this as a real issue, do you?

Fabiola De la Cueva: @Adam Gotway, that is a question for NI. You could add it to the NI Forum Idea Exchange group

Lori Hanson: @Matthias || Pause

Adam Gotway: It definitely makes the tool less useful

Fabiola De la Cueva: @Boyd Crow 2, when in youtube hover on the lower right and you can change the speed to go a lot slower

Chris Chiccone: Isn’t a distributed source control similar to having a dev and trunk in a centralized source control system?

Christopher Tyler: @Fab — thanks for the links!

Boyd Crow 2: And I can ask questions at that time?  I don’t think so.

Matthias BAUDOT: @Adam Gotway You can revert to a previous version and run your code from there if ytou need

Chris Chiccone: you can essentially peak at the trunk and update the dev if needed

Fabiola De la Cueva: @Boyd Crow 2, no, you cannot, but you can post questions on the forums.

Justin Thompto: <- this guy

Chris Chiccone: and it all stays on a server instead of local

Ryan Delgizzi: Fab, you mention having one owner of each class file, and they are responsible for making changes to that file.  Developer 2 adds a vi and wants to commit it. Do you leave that VI thinking its a memeber of the library, or do you submit it as an individual VI that is broken because it may not have access to class data?

Tim Cormier: Grab those links now! They don’t seem to get included when NI sends webinar lin 

Fabiola De la Cueva: @Chris Chiccone: Centralized is only one trunk or branch.  Distributed you have a local repository in your computer where you commit and update from and then you have the option to push/pull to all the other clones your team members have.

Fabiola De la Cueva: Yes, copy the comments now, I will try to get a copy from NI for the chat and I will edith this post to add them there:

Matthias BAUDOT: @Ryan Delgizzi You save it as a member of the class, but dont save the class. Then you coordinate with the class owner to have him updating the class and commit it

Fabiola De la Cueva: @Ryan Delgizzi, The developer adds the VI to the library but doesn’t save the library, asks the owner to add it

john orourke: no

Fabiola De la Cueva: if the owner doesn’t get the memo, when the VI is opened, LabVIEW will complain that the VI seems to think it is part of a library and the library does not recognize it

Chris Chiccone: Thanks Fabiola, I see how it’s an extra step to always branch/update the trunk rather than simply pushing to the server

Fabiola De la Cueva: so LabVIEW will do the remininding for you

Scott Doyle: Ok, so the reason that I haven’t pushed an SCC onto our other programmer’s is the HOW:  HOW do I set up an SCC and train them when I don’t really know what I’m doing?  Is it better to just start small on my own and then train them once I understand?  Is there a best practices guide?

Fabiola De la Cueva: @Chris Chiccone, yes, BTW, you can configure distributed to function as centralized. Basically it turns the commit+push and the pull+update into single step actions.

Remy Fenouil: So if the VI is “too large” does the compare just run really slow/take a while or does it crash the compare????

Ethan Jenkins: Is it true that VI files are also moving to an XML-based format soon?

Fabiola De la Cueva: @Scott Doyle, at Delacor we do help teams figure out what is better for them. We provide some blog posts on our blog, but we also offer consulting services to help you figure out more details.

Chris Chiccone: That makes sense… I was justing thinking of way to make a centralized into distributed model, which is essentially making a separate dev branch for each individual developer and having one common trunk branch

Matthias BAUDOT: @Scott Doyle I suggest you contact Delacor (Fabiola) directly to get help. This is typically what they are doing for customers. Helping them getting starrted and implementing best software engineering practises

Fabiola De la Cueva: @REmy Fenouil, unfortunatelly if hte VI is too large or too different… LabVIEW Compare crashes

Chris Chiccone: I believe perforce makes this easier now with the new streams feature where the master knows all of its children development branches

Ryan Delgizzi: Thanks Fab, have you had any issues with that process leaving the code broken?  Or is it simple enough as long as you are diligent about making updates promptly?

Remy Fenouil: well that’s not very helpful….

Fabiola De la Cueva: @Ethan Jenkins, VIs will be XML based for NXG, not for current LabVIEW

Fabiola De la Cueva: @Chris Chiccone, you acan acieve that in Git with SubModules. You have a top repository that has a list of dependent sub-repositories

Scott Doyle: ok, thanks.  I think this Process and Architecture Smells slide is a basic start…and too many coworkers do too many of the Avoid items for me to feel comfortable pushing somethign on them when I can’t get them to follow those guidelines in the first place

Steve Maher: Funny how the talk extols the value of source code control but the tools needed  (LVCompare and LVMerge) are only available in the high-end Labview version

Chris Chiccone: Great, thanks Fabiola!

Fabiola De la Cueva: @Ryan Delgizzi, my customers have found out that if their code is very modularized, then each developer works on a separate library and they don’t have to deal with this issue of having multiple developers work on the same library.

Fabiola De la Cueva: @Scott Doyle, you are correct, if they are not using good programming practices, this might be harder. Selecting a common framework or way of work goes a long way.

Fabiola De la Cueva: Steve Maher, LabVIEW Compare and Merge are included in the Dev edition of LabVIEW… they used to cost extra, so at least no it is part of that version 🙂

Matthias BAUDOT: @Scott Doyle If you still want to investigate SCC by yourself, I definitely suggest you to start with SVN. It’s a lot easier

Scott Doyle: We have some common frameworks, but I recently realized that they aren’t modularized enough yet.  We’re still very silo’d in our development.

Fabiola De la Cueva: If you are already working on Silos, have each developer start using SVN on their own

Scott Doyle: Could you explain that statement Matthias?

Fabiola De la Cueva: hopefully they will see the benefits

Fabiola De la Cueva: eventuahlly when you get to work more as a team, then you can look into going into distributed source code control

Scott Doyle: ok, just send them Tortoise SVN and hope for the best?

Fabiola De la Cueva: ja ja ja

Fabiola De la Cueva: @Scott, send them the link to the blog post

Fabiola De la Cueva: and have them go through the hands on manual… let me look for it

Scott Doyle: But, there is a concensus of Tortoise SVN over Mercurial for developers new to SCC?

Fabiola De la Cueva: a lot of goodies for Software Engineering available here:

Tim Cormier: I haven’t heard anyone mention that for any SCC to be of benefit, you need to separate your compiled code.

Matthias BAUDOT: SVN is a lot better integrated into LabVIEW, especially with the TSV Toolkit from Viewpoint (available for free on the LabVIEW Tools Network). You don’t have the same power of branching and distributed SCC with SVN compared to Git or Mercurial, but you will have the “Time Machine” wih comments for your commits. Thats probably the most urgent thing to implement

Fabiola De la Cueva: specificallly code management:

Steve Maher: According to, graphical diff and merge only available in Labview Professional

Matthias BAUDOT: @Scott Doyle Once you know how to work with SVN in your team, its not a big deal to then switch to distributed SCC (Git or Mercurial) if you need. But getting from nothing to Git, with LabVIEW might be tricky if you dont know SCC already

Casey May: @Tim  My understanding is that separating compiled code helps reduce size, but isn’t necessary. I used to use SCC without separating compiled code with no problems.

Fabiola De la Cueva: @Tim Cormier, definitelly, you need ot separate source code from compiled code. On this blog post:  on the SVN section on minute 9:10, the video shows how to separate source code from compiled code

Matthias BAUDOT: @Tim Cormier Absolutely right!

Fabiola De la Cueva: Separating source code from compiled code also helps with the : I just changed one typedef and now LabVIEW says that 50 VIs changed

Matthias BAUDOT: Separate source code from compiled code allows you to only track changes that you make, and not changes that are due to recompilation of callers or dependenciy VIs

Tim Cormier: @Casey if  you don’t separate compiled code, SVN flags nearly everything as changed, due to the fact that LV is constantly recompiling VIS

Matthias BAUDOT: it is part of the good practise when using SCC with LabVIEW

Scott Doyle: It would be better to start with Tortoise SVN, then switch to Hg, then to just start in Hg and only have one learning curve to travers?…?????

Casey May: @Tim Gotcha, that’s part of what I meant by size benefits

Fabiola De la Cueva: @Scott, the Hands On manual for software engineering practices including learning how to use SVN, check out

Lori Hanson: @Steve Maher I highly agree, SCC should be introduced early and often – the educational, hobbyist, and intro LV versions should have some form of this. If it is not taught early, it is hard to expect developers to use it.

Matthias BAUDOT: @Scott Doyle Agreed !  @Fab, do you also agree?

Adam Gotway: Gotta manually mark as resolved. That is not intuitive.

Casey May: One caveat with separating compilied code though is that it can break some plug-in architectures when you go to build your projects

Tim Cormier: but it’s much more than size of VIs. You won’t be able to tell which VIS actually changes.

Remy Fenouil: so in labview how do you know the difference between source code and compiled code?

Fabiola De la Cueva: @Lori Hanson, LabVIEW Compare and LabVIEW MErge are not absolutely needed for Source Code Control

Zach Hawkins: If yo”e looking to switch from a Centralized System to a Distributed System, I would also urge many of  you to look at PlasticSCM.

Boyd Crow 2: THe demo is continuing to run during answer to question.

Fabiola De la Cueva: You can use Source Code Control with even the LabVIEW Base version

Remy Fenouil: in LabView specifically…

Fabiola De la Cueva: @Scott Doyle,  SVN is a lot easier to learn, then learning Hg would be a lot easier to learn once you are comfortable and familiar with SVN. Especially if you don’t have a team to support you.

Lori Hanson: As an educator, any tools I can get students using that shed light on the need for future more sopphisticated TEAM SCC aspects…the happier I’ll be 🙂

David Wilt: @Scott Doyle I went right to Hg without knowing SVN and did not have any trouble

Tim Cormier: @Casey – re plugins, I believe there are are procedural solutions to that issue.

Fabiola De la Cueva: @Remy Fenouil, having source code separated from compiled code is something LabVIEW uses behind the scenes. You don’t need to worry about where things are saved. LabVIEW takes care of it. You just continue to use LabVIEW as you have always done.

Casey May: @Tim I’m not in disagreement

Casey May: @TIm But there are trade-offs for each solution

Adam Gotway: Ludicrous speed!

Fabiola De la Cueva: @Lori Hanson, definitely, I have taught SVN and Hg to FIRST Robotics teams and other robotics teams even as young as 10 years old

Boyd Crow 2: I will now have to spend at least another hour locating the few things I did not already know about Mercurial.  Fabiola is clearly well versed in this subject but too fast for we mortals to follow.

Lori Hanson: I begin as early as 6 and go through college levels. I really relate to your “I didn’t change anything” defense.

Scott Doyle: Thanks everyone!!  I think that article by Elijah is where I will start.  I actually have Tortiose installed already, but didn’t really know how to go forward….at least not without unknowingly making a lot of fundemental mistakes.  Plus, I believe that ideally our group will work best in the long term with Hg and still didn’t know how to get started.

Fabiola De la Cueva: @Lori Hanson, let me know if I can make other videos that would help your kids. Our Delacor Youtube channel is

Jorge Luis Orta: so at the end Git or Mercurial?

Fabiola De la Cueva: @Scott Doyle, start with Elijah’s manual, then revisit the two Delacor Blog posts:

Tim Cormier: @Casey – agreed. 🙂

Fabiola De la Cueva: If you have questions, feel free to comment on those blog posts

Lori Hanson: Thank you. I am really keen on creating games and physical activities that teach the physicality of the events. Then they appreciate what the automated SCC systems provide.

Steve Maher:  How do you do SCC in Base version?

Tim Cormier: Can someone post the link to Elijah’s manual?

Fabiola De la Cueva: @Jorge, answering in the video now: Git is a lot more powerful, I find my customers get very confused by it. Hg has been a lot easier to get people to get up to speed.

Scott Doyle:

Jeffrey Mach: the

Adam Falkowski: will SCC tools like Git and Hg work with TestStand files as well as the LabView files?

Jeffrey Mach: the\LVscc link is broken.

Tim Cormier: @Scott Dolye: – thanks!

Jorge Luis Orta: so for HG do you sue Bitbocket?

Fabiola De la Cueva: @Steve Maher, LabVIEW Compare and LabVIEW Merge are not needed by source code control. You can still use source code control wihtout these tools. You won’t be able to diff, merge, but if you are organizing your code correctly, you should not need those tools.

Matthias BAUDOT: Git, SVN, Mercurial are tools that work for all programming languages. it is not specific to LabVIEW. so you can do SCC with anything and any version of LabVIEW

Jeffrey Mach: nevermind…didn’t know that it was Case-Sensitive.

Scott Doyle: Your welcome @Tim Cormier

Fabiola De la Cueva:\LVscc is case sensitive

Adam Falkowski: @Matthias thanks

Fabiola De la Cueva: We use Bitbucket with both Hg and Git

Matthias BAUDOT: LabVIEW Merge and LabVIEW Diff tools are tools from NI specifically for LabVIEW to be used concurrently with SCC. They are not especially needed if you have good programming practises

Brian Shea: has anyone mentioned using the exclude files to exclude files from SCC?

David Wilt: @Adam Falkowski I used Hg with TestStand  there are tools to diff/merge sequence files available

Fabiola De la Cueva: link for Eli’s manual:

Adam Falkowski: @David that’s good to know, thanks

Fabiola De la Cueva: the case sensitive link

Fabiola De la Cueva: @Brian Shea, list of excluded files:

Scott Doyle: Wait, so you have a video that walks through how to properly setup Hg?  It’s still better to start with SVN?  I understand the concepts of SCC, I don’t know the details.  Does that make a difference?

Fabiola De la Cueva: @Matthias, video is asking if BLT works in Real Time

Jeff DeBuhr: Thanks FAB

Carse Crews: Thanks

Sean Coffey: Thanks

Trent Schatz: Thanks

William Luu: Thanks

Reto Seeholzer: thanks

Virmantas Masaitis: Thanks

Said Al-sammak: thanks

Kallie Luptak: Thank you

Chris Chiccone: thanks

Patrick Zintak: THANKS

Jeff Murphy: good presentation, thank you

Fabiola De la Cueva: @Scott Doyle, if you already understand the concepts, then do start with Mercurial (Hg)

Matthias BAUDOT: Unfortunately, the current release of BLT doesnt handle RT. It will be available in the next major version

Adam Falkowski: great presentation, thanks Fabiola!

Christopher Tyler: @Fab — The presentation was a good start but your comments during was really good, thanks!

Lori Hanson: Thank you.

Henry Tran: thanks!

Leland Bryton: Thanks

Tim Cormier: All the links that I could grab while still following!

Fabiola De la Cueva: Glad you guys liked it. I will get the chat comments and add them to this blog post: 

Scott Doyle: Ok, sweet.  Thank you very much for all of the advice!!!

Jorge Luis Orta: great presenstation

Jorge Luis Orta: thanks

Mehul Shah, Multimedia Specialist: thanks Fabiola

Jorge Luis Orta: I guess you get a notification everytime someone post a question on your blog right

Scott Doyle: lol.  Awesome job @Tim Cormier

Brian Jahraus: Thank you!

Fabiola De la Cueva: I know I talk too fast and there was tons of information. I wanted to make sure you got a 0 to 100% overview and you could go figure out the details on your own.

Fabiola De la Cueva: You can always slow down the videos on youtube ; 

Fabiola De la Cueva: @Tim Cormier, thanks, I will also add the comments to the blog post

Fabiola De la Cueva: @Jorge, yes, I do

Scott Doyle: Agreed @Christopher Tyler.  I’m not sure how much I even watched the video – but I can watch that later.  The chat with all those with all of the knowledge was in real-time.  😉

Fabiola De la Cueva: @Jorge, if you want to get access to a lot more knowledgeable people, you can post on the ni forums too

Steve Maher: WIth 30 years CS under my belt, I’d say doing SCC without compare and merge gives a false sense of security.   Without compare and merge it’s just a backup system.  I commend your overall message but contend the merge/compare tools should be avaialble at all levels.

Fabiola De la Cueva: @Steve Maher, this is something that I don’t know if we just have evolve because we don’t have the tools or if it is the language driven. I have seen that successful teams in LabVIEW tend to modularize their code a lot more than text-based programmers do.

Fabiola De la Cueva: LabVIEW teams also tend to be a lot smaller.

Lori Hanson: @steve maher  We are old school — best programming practices are not taught now – they need to be monitored. I’m with you.

Fabiola De la Cueva: so working on a single module happens a lot more often than having multiple people working on the same module at once.

Fabiola De la Cueva: If your VIs are huge that require regular use of LVCompare and LVMerge, I would look into breaking them into smaller pieces, using more libraries/classes, etc.

Fabiola De la Cueva: @Steve Maher, that said, please post on the Idea Exchange that these tools should be available at all levels and I will vote for your idea.

Lori Hanson: The reality is, today everybody and their brother are programmers. They are not formally trained, but can perform the programming. We need ways to harness this. I see value in having more tools.

Fabiola De la Cueva: link to idea exchange:

Fabiola De la Cueva: @Lori Hanson: tools without training are just weapons of mass destruction

Fabiola De la Cueva: 😉

Fabiola De la Cueva: the tools by themselves will not protect them from themselves

Scott Doyle: Thanks again!  I really appreciate the feedback.

Fabiola De la Cueva: @Scott Doyle, glad it helped. Good luck and I am glad you will start using source code control.

Danny Thomson: A book called “Software Configuration Management Patterns” by Stephen . P Berczuk is interesting for av little deeper read

Jeff DeBuhr: Fab, I always enjy your presentations, thanks again

Steve Maher: You missed it – I already posted this.  (Idea was declined from someone else).

Fabiola De la Cueva: @Steve Maher, you can still comment on that idea

Mehul Shah, Multimedia Specialist: @everyone, we’ll be closing the room in the next few minutes, if you have any last minute questions for Fabiola

Steve Maher: Er, so “Declined” ideas get reconsidered?

Mehul Shah, Multimedia Specialist: Fabiola will post the discussion to the forum

Fabiola De la Cueva: @Steve Maher, you can do that or call your sales representative and express your opinion.

Fabiola De la Cueva: NI cannot read minds, if enough people reach to them with the same request something will be done

Fabiola De la Cueva: that is how we finally got Event Structures in the Base version

Fabiola De la Cueva: @Reto Seeholzer, the presentation on AF and DQMH can be found here:

Fabiola De la Cueva: @Tim Cormier, separating source code from compiled code is a single option in the LabVIEW options. You just have to check a box. More details shown on the video on SVN at minute 9:10 on this blog post:

Mehul Shah, Multimedia Specialist: any other questions before I close it out

Mehul Shah, Multimedia Specialist: @Fab, please make sure to get the chat, and I can send it to you as well

Fabiola De la Cueva: @Mehul, please send it to me, I was glued to my keyboard and I didn’t get to copy from the beginning

Mehul Shah, Multimedia Specialist: just sent

Fabiola De la Cueva: thanks!

Mehul Shah, Multimedia Specialist: alright eeryone, I’ll be closing out the room

Mehul Shah, Multimedia Specialist: thank you all for attending the series!


Below is a video of the presentation given at Austin, TX. If you want to see the demonstration videos only, they are found via the playlist (it also includes the videos from the Every Developer Needs a Time Machine post).


I know this cartoon is getting old, but there were still two people in the presentation that said: “I don’t use source code control because I am a single Developer”… so, maybe the world needs to see it again 😉 Seriously, if you are not using SCC, you are playing with fire!

While preparing this presentation, I realized that in the LabVIEW Community, we tend to call it Source Code Control. However, the rest of the world calls it Version Control Systems (VCS), Source Code Management (SCM) or RCS (Revision Control System). I think it is important to share these new terms to help you in your search for more information.

One thing I have learned while working with different teams is that every project, regardless of size, benefits from Source Code Control. A good way to figure out if you should use source code control or not is to think about how many hours of your day you are willing to lose if your project gets corrupted. Make this your trigger to decide whether or not to use Source Code Control.

One more thing, SCC commits without comments are like a movie script without the main plot. It is not just having a track of revisions and what changed, commits are also a good way of sharing the developer’s state of mind and share intent. They are an investment in your Technical Wealth. Recently, one of our customers mentioned that a feature had disappeared along the way. We were able to figure out that the VI was modified several times, specifically, there was a commit from October 2015 that said the customer had requested for us to remove the feature and pointed to a case in JIRA. The JIRA case had the customer’s reasoning to request the change. It is OK for our customer to change his mind, but we were able to share what his reasoning was back then. He requested to reimplement the feature, and the code from October 2015 was there for us to see and reimplement. We did not have to reinvent the wheel. In addition to the commits and the JIRA case, the developer who removed the feature had left bookmarks in the code and Unit Tests to verify that the feature would work well it was ever reimplemented.

What is Source Code Control?

I don’t think I exaggerate when I say that the most important technical asset for any software development team is their source code control tool. It keeps track of every modification done to the code. Developers can “travel back in time” to see what the code looked like in the past, and revert changes or determine when a bug was introduced

No more:

We have seen these names. No customer was hurt while we gathered these names!

Centralized Source Code Control

A central copy of the project is in a repository (typically a server). Developers “commit” their changes to that central location. Examples: CVS, SVN, Perforce

Step 1: Checkout Working Copy

Step 2: Developer makes changes and commits

Step 3: Other developers get the change by updating their copies

Step 4: If two developers make a change, whoever gets second needs to update first and resolve any conflicts

Centralized Source Code Control: Disadvantages

  • Developer requires a connection to the repository in order to commit, update or read the log.
  • When committing, they need to address conflicts right then and there.
  • Developers do not commit as often in fear of conflicts or breaking others’ code.
  • Repositories tend to get too large because developers can only check out the section they are working on.
  • Having the entire code base in a single repository means that if something happens to the repository, the entire code base is affected
  • Leaves risk of developers calling source code in different parts of the repository as opposed to built/released code
  • Managing the history of a project is difficult because it is combined with the history of other projects

Distributed Source Code Control

A central copy of the project is in a repository (typically a server). Each developer has a clone of the entire repository. Developers “commit” their changes to a local repository and “push” their changes to central location. Examples: Git, Hg (Mercurial)

Step 1: Clone Repository

Step 2: Developer makes changes and commits as many times needed to the local repository

Step 2a: When ready, push commits

Step 3: Other developers get the change by pulling the changes into their local repository

Step 3a: When ready, update

Step 4: If two developers make a change, whoever gets second, pulls and can choose to update, resolve any conflicts and push when convenient

Branch Merge vs Code Merge

Branch merge: When the files of a project have been modified in two separate branches and get combined into a single branch. Different developers can work on different branches. This may or may not involve merging code.

Code merge: When the same code file has been modified in two separate locations and get combined into one final version of the code.

The video above shows all the steps for distributed source code control described before:

  • 00:00 Cloning on both computers
  • 00:24 Fabiola creates a new project and commits it
  • 00:48 Fabiola pushes changes
  • 01:02 Jane Pulls changes
  • 01:16 Jane Updates to the different commits Fabiola did
  • 01:39 Jane adds a new library. This is going to be used to show how to handle the project. In this particular example, Jane decides to not commit the project and instead asks Fabiola to add it via the commit notes.
  • An alternative (not shown in the video) is for Jane to push the project changes and then let Fabiola resolve. In that case, Fabiola could update to see what Jane had done to the project and then decide if she takes the local copy or Jane’s copy. A third alternative is to merge the project file as a text file, however, this can result in a corrupt project.
  • 02:05 Fabiola pulls and updates Jane’s changes
  • 02:35 Fabiola adds the missing files to the project
  • Starting at minute 3:00 the video describes an ongoing project, where both Fabiola and Jane are making changes to the code. Never to the same file.
  • Jane has pending changes. She has committed but she has not pushed her changes yet.
  • She updates to the different versions Fabiola pushed, taking a peek to see that Fabiola changed the button text on one commit and added the Hello World code on the next.
  • 03:52 Jane is done taking a peek and goes back to her own version, where she makes more changes, commits and then when she is ready, she merges the changes with Fabiola’s changes.
  • There are no conflicts to resolve because they were working on different files the whole time. This is an example of a branch merge.

LabVIEW Compare

LVCompare.exe is equivalent to “Compare VIs dialog box” found in Tools>>Compare>>Compare VIs. It is available only in the LabVIEW Professional Development System. Works like those “Find the differences” games we did as kids:

Remember it is “Find the differences” not “Where’s Waldo?”

Code image was taken from the Rube-Goldberg-Code post in the NI forums.

LabVIEW Merge

LVMerge.exe is equivalent to “Merge VIs dialog box” found in Tools>>Merge>>Merge VIs. It is available only in the LabVIEW Professional Development System.

Just like LabVIEW Compare, it works better with small changes in small block diagrams.

Process and Architecture Smells

Throughout the years, I have encountered that the insistence on having LVCompare and LVMerge configured in the source code control tools is a process/architecture smell. It should be very rare that a developer needs to use either tool. Really the only valid frequent use for LabVIEW Compare is, in a regulatory environment, the Q&A person requests to see a redline comparison of what changed. 

Architectures where the VIs are coupled and not cohesive lend themselves more to developers needing to work on the same VI as another developer for implementing different features.

Library files: .lvlib, .lvclass, .lvproj are XML files, so you would think they are text files, except when they are no longer text files!. These files do include some binary information. Regular text compare tools can be used to identify some changes, but merge tools should be avoided, they can corrupt the files. 

At Delacor, we assign an owner for the library files. If two developers are working on the same library (but in different VIs) and they need to make a change to the library, they request the owner to make the change or check with the owner if it is OK for them to make the change.

Configure LabVIEW Compare

Find details on how to configure source code control with LabVIEW Compare in LabVIEW Help

While the information is there on the help, there are some caveats to consider when configuring third-party source code control tools.

Edit March 26, 2020: We are using Git-Fork for Git and we are liking it a lot more than SourceTree. It is also a lot easier to configure LVCompare, here is how you configure it:

Diff Tool Path: C:\Program Files (x86)\National Instruments\Shared\LabVIEW Compare\LVCompare.exe
Arguments: “$LOCAL” “$REMOTE” -nobdpos -nobdcosm

Git Fork LVMerge and LVCompare configuration

LabVIEW Compare requires some LabVIEW wrapping to make it work with Mercurial. To find the tool, go to the Mercurial user group at NI ForumsAndreas S, System Engineer at NI created a tool that wraps LVCompare so it can be called from Mercurial. James McNally made some changes and both tools are available via Bitbucket. Edit: Thanks to Ryan Vallieu for pointing out this other tool available via GitHub.

Also, our friends at Endigit published a blog post on how to configure SourceTree to use LabVIEW Compare.

The video above describes how to configure TortoiseGit to use LabVIEW Compare as its Diff tool and the LabVIEW Merge to resolve conflicts.

At minute 1:00, the video shows how to configure TortoiseGit to use LVMerge to edit conflicts.

The video above shows a simple change in code. In this case, just changing the Boolean text on a button, then using TortoiseGit>>Diff to launch LabVIEW Compare and compare the changes.


Configure LabVIEW Merge

Edit March 26, 2020: We are using Git-Fork for Git and we are liking it a lot more than SourceTree. It is also a lot easier to configure LVMerge, here is how you configure it:

Merger Path: C:\Program Files (x86)\National Instruments\Shared\LabVIEW Merge\LVMerge.exe
Arguments: “$BASE” “$REMOTE” “$LOCAL” “$MERGED”

Git Fork LVMerge and LVCompare configuration

Find details on how to configure source code control with LabVIEW Merge in LabVIEW Help.

The video above shows a simple change in code. In this case, just changing the Boolean text on a button, then using TortoiseGit>>Diff to launch LabVIEW Compare and compare the changes.

The video above shows how to configure Mercurial to use LabVIEW Merge.

The video above shows the same thing that was shown in the Git video, but using Hg instead. This video shows the concept of a feature branch. The code will be changed both in the “master” branch and in the “feature1” branch.  Since the same file has been modified in both branches, there will be a conflict. We configured TortoiseGit earlier on to use LVMerge.exe for conflicts.

At minute 2:31, a conflict is detected and the video shows how to launch LabVIEW Merge to compare the changes and decide which ones stay and which one are not part of the merged VI.


Distributed Source Code Control does not require a connection to the central repository all the time

Every team member has a complete copy of the repository including the entire metadata

It is still advisable to have backups of the repository, but they are not as crucial as with Centralized Source Code Control

Avoid working on the same VI on different branches

Overuse of LabVIEW Compare and LabVIEW Merge is a symptom of an architecture that is not modular enough and/or a process that has multiple developers working on the same code at the same time


Special thanks to Matthias Baudot from StudioBods for helping me with some of the videos on this post.

19 responses to “Configuring Hg or Git to use LabVIEW Compare and LabVIEW Merge”

  1. Jason Swoboda Avatar

    This article was incredibly helpful getting Tortoise Git setup for LabVIEW Compare and LabVIEW Merge tools. I had done so successfully in the past with Tortoise SVN and it was harder to find the same resources for git.

    IMPORTANT: The video “Git and LV Compare Setting up Git (with audio)” has the correct configuration string for both tools, however if you cut and paste directly from the video you end up with “ and ” around the path instead of the ” symbols. This didn’t work for me until I substituted the ” symbol in place and it worked fine after that.

    1. Fabiola De la Cueva Avatar
      Fabiola De la Cueva

      Hi Jason,
      Glad you found this article useful.

      When you say you copied from the video, do you mean from the comments in the video when opened directly via YouTube?
      I edited the comments there, hopefully that has the correct character now.

      Thanks for the feedback,

      1. Callum Ellor Avatar
        Callum Ellor

        Hi Fab,

        Thanks for the videos on how to configure git to compare and merge with LabVIEW. I am having some issues getting the compare tool to work with TortoiseGit.

        I have entered the following line:

        “C:\Program Files (x86)\National Instruments\Shared\LabVIEW Compare\LVCompare.exe” %mine %base -nobdcosm – nobdpos

        into the external program field as per your video but I seem to get the following error. Do you have any suggestions as to why this might be happening?

        LVCompare was called with incorrect parameters.
        How to call LVCompare:
        LVCompare [-lvpath ] [-noattr] [-nofp] [-nofppos] [-nobd] [-nobdcosm] [-nobdpos]
        [-lvpath ] – Provide the path to the LabVIEW executable you want to compare the Vis

        Ideally I would like to setup TortoiseHg to use LabVIEW compare as I feel that this is a very easy version of source code control to use and I can try and introduce this to my company. The only thing it can’t do that I am aware of is the LabVIEW compare functionality. I’ve searched online for a method of doing this but I am not having much joy. Do you have any thoughts on how to implement this functionality?



        1. Fabiola De la Cueva Avatar
          Fabiola De la Cueva


          Looks like you might be having the same issue Jason pointed out and that your path is not surrounded by the right “” symbol.

          You have entered:
          “C:\Program Files (x86)\National Instruments\Shared\LabVIEW Compare\LVCompare.exe” %mine %base -nobdcosm – nobdpos

          Where it should be:
          “C:\Program Files (x86)\National Instruments\Shared\LabVIEW Compare\LVCompare.exe” %mine %base -nobdcosm – nobdpos

          Subtle, but try that out and let us know if it works. (BTW, when the post is published, both quotation marks look exactly the same, but if you copy the text and paste it in Word and change the font, you might see the difference in the quotation marks).

          The error is saying that the path to LabVIEW is wrong, so the only thing I can think of is the quotation marks.


  2. Ryan Avatar

    Thanks for the article Fab. Currently working as a single developer, but will be adding team members in the near future.

    I was worried about the compare and merge tools in LabVIEW, but this blog post helped me get up and running.

    1. Fabiola De la Cueva Avatar
      Fabiola De la Cueva

      Hi Ryan,

      Glad this blog post helped you.
      We will continue to add source code control related blog posts, they will all be grouped under

      If there are any particular topics you would like us to cover, please let us know.


  3. Terry Avatar

    Thanks for making this info and videos public. I believe they are the best online resources for LabVIEW and source code control. Lately, I have been sharing these links with my customers. Keep up the good work!

  4. Fabiola De la Cueva Avatar

    Hi Terry,

    Glad you are finding the videos and blog posts useful. Please let us know what other topics you would like for us to cover and we will add them to the list for future posts.

    Thanks for taking the time to comment.

  5. Ryan Vallieu Avatar
    Ryan Vallieu

    Shoot – no instructions for Sourcetree.

    1. Fabiola De la Cueva Avatar
      Fabiola De la Cueva

      Hi Ryan,

      Our friends at Endigit have a blog post on how to configure LVCompare via SourceTree. Check it out at

      Also, thanks for the comment, it made me realize that the link in my blog post was pointing to their blog instead of the specific article. I will fix it asap.


      1. Ryan Vallieu Avatar
        Ryan Vallieu

        I found that post and it was incorrect.
        I have found that a previous NI Employee made a LabVIEW tool that parses the relative paths to the ABS paths that LV Compare and LVMerge need to function.

        The code is shared on GitHub and is accessible. I have cloned and tested it and it works. The Endigit one was missing half the args from the Merge. I posted that and it seems they are fixing that oversight.

        1. Fabiola De la Cueva Avatar
          Fabiola De la Cueva

          Hi Ryan,

          Thanks for your comment and for pointing us to the GitHub repo. We will check it out.


  6. […] LabVIEW diff with merge, there is a good article here from […]

  7. Andrew Avatar

    Hi Fab,

    Big fan of your awesomeness here. So I’m trying to get diff viewer to work, I replaced the quotations with the correct ones as the comments above suggest. Here is my program config string…

    ”C:\Program Files (x86)\National Instruments\Shared\LabVIEW Compare\LVCompare.exe” %mine %base -nobdcosm – nobdpos

    When I go to TortoiseGit –> Diff, I get this error…

    Could not start external diff program!
    The system cannot find the file specified.

    I’ve confirmed that LVCompare.exe is at the expected path. I’m running LabVIEW 2017 and TortoiseGit

    Any help is greatly appreciated. Thanks!

    1. Fabiola De la Cueva Avatar
      Fabiola De la Cueva

      Hi Andrew,

      Thanks for the compliment! I am just Fab 😉

      I am using now the client called Fork, I am loving it, you may want to give it a try at
      I edited the original post to include how to configure LabVIEW Merge and LabVIEW Compare in Fork, I included a picture.

      That said, I installed, just for you, TortoiseGit to try to reproduce the error you are seeing.

      1) Make sure that the menu option for LabVIEW Compare is available on your LabVIEW menu (see )
      2) How are you launching the diff tool? I made a simple change to a VI that I had in a Git Clone. Then, once it was showing the red overlay icon, I right-clicked on it and selected “TortoiseGit>>Diff”. LabVIEW Compare showed up without any issues.

      In the Fork client, when a VI shows on the Changes section, I right-click on it and select “External Diff”

      Let me know if this helps you fix the issue you are having.

      Thanks for your trust,

      1. Andrew Avatar

        I’ll have to bring up Git-Fork to my supervisor, although as a company we are a bit hesitant to change, we are fairly new to software configuration control to begin with.

        I did figure out where my problem was though. First off, the “normal” quotation marks worked but the other ones (“ “) did not. Guess they’ve updated it recently or something. Secondly, in the comments with Callum there’s the slightest error in the program config string: [– nobdpos] (n-dash with a space) needs to be [-nobdpos] (hyphen with no space). For the heck of it, I tried using [%mine %base –nobdcosm –nobdpos] (both n-dashes with no space) and it didn’t work… must use hyphens for the options.

        Thanks for the quick reply though! Was not expecting to hear back so fast once I saw that the last comment was a year and a half old.


        Andrew Casalenuovo
        Test Engineer
        Moog Inc.

        1. Fabiola De la Cueva Avatar
          Fabiola De la Cueva


          Glad you figured it out and thanks for sharing what you found out with everyone else.

          I was able to get to it so fast because I was working on a git clone at the moment.

          I still don’t know where the different quotations come from. I know that when I was writing the book, the editor kept correcting the quotation marks on my draft 😉

          Happy wiring,

  8. David Wilt Avatar
    David Wilt


    First off, thank you for putting this together I always find my self referring back to it.

    I have recently transitioned to Git from Hg and I know that you have stated you recommend Fork so I have looked into it. One issue I am having with Fork is that it appears you can only configured 1 external Diff tool, am I missing something? As I use both LabVIEW and TestStand having 2 external Diff tools is required.

    I have put in a support question with Fork but I have not received a response to this question.

    I am wondering if you have had this issue with supporting multiple external Diff tools and how you get around the issue.

    Thank You,
    David Wilt

  9. Gabriel Avatar

    Dear Fabiola

    Thanks a lot for this great post. I am successfully using LabView with git-fork. It is very handy to use this enviroment for version control. However I have a very annoying problem.

    When using Shared Variables, git shows that the VI containing a Shared Variable had been changed even nothing has changed. The only difference is, taht the VI had been opened on a different PC than it was created. Hence the difference seems to be related to the absolute path of the relative variable… When comparing the changes LabView shows the following: Difference on “Block Diagram objects”, Deaitl: Shared Varaiable: target relative.

    Is there any option to let git know (or LVCompare) that it does not check for such changes. (at the moment I use this .gitignore file

    At the moment this is very missleading, as the only thing that has changes is the source path of the repository from one PC to the other… And it makes collaborative working hard.

    Thanks for your help.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.