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: http://delacor.com/configuring-hg-or-git-to-use-labview-compare-and-labview-merge/
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: https://github.com/github/gitignore/blob/master/LabVIEW.gitignore
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, http://delacor.com/configuring-hg-or-git-to-use-labview-compare-and-labview-merge/ 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: http://delacor.com/configuring-hg-or-git-to-use-labview-compare-and-labview-merge/
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 http://delacor.com/every-developer-needs-a-time-machine/
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: ni.com/largeapps
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: https://learn.ni.com/labview-center-of-excellence/resources/84/code-management
Steve Maher: According to http://www.ni.com/en-us/shop/labview/select-edition.html, 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: http://delacor.com/every-developer-needs-a-time-machine/ 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 https://forums.ni.com/t5/LabVIEW-Development-Best/Software-Engineering-Technical-Manual-and-Exercises-for-LabVIEW/ta-p/3492607
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 youtube.com/delacorllc
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: http://delacor.com/category/scc/
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: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-LVdiff-and-LVMerge-available-for-all-labview-versions/idi-p/1507632/page/2#comments. 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.
Jeffrey Mach: the bit.ly
Adam Falkowski: will SCC tools like Git and Hg work with TestStand files as well as the LabView files?
Jeffrey Mach: the bit.ly\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: bit.ly\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: bit.ly link for Eli’s manual: http://bit.ly/lv_swe
Adam Falkowski: @David that’s good to know, thanks
Fabiola De la Cueva: the case sensitive link http://bit.ly/LVscc
Fabiola De la Cueva: @Brian Shea, list of excluded files: https://github.com/github/gitignore/blob/master/LabVIEW.gitignore
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! https://forums.ni.com/t5/LabVIEW-Development-Best/Software-Engineering-Technical-Manual-and-Exercises-for-LabVIEW/ta-p/3492607
http://delacor.com/category/scc/
https://learn.ni.com/labview-center-of-excellence/resources/84/code-management
http://delacor.com/every-developer-needs-a-time-machine/
http://delacor.com/configuring-hg-or-git-to-use-labview-compare-and-labview-merge/
https://github.com/github/gitignore/blob/master/LabVIEW.gitignore
http://delacor.com/configuring-hg-or-git-to-use-labview-compare-and-labview-merge/
http://delacor.com/every-developer-needs-a-time-machine/
http://delacor.com/every-developer-needs-a-time-machine/
https://www.youtube.com/playlist?list=PLZ3A_SIOKdQvUnA5U7Vuz-teKbcVcTnk4
Fabiola De la Cueva: Glad you guys liked it. I will get the chat comments and add them to this blog post: http://delacor.com/configuring-hg-or-git-to-use-labview-compare-and-labview-merge
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: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas
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). https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-LVdiff-and-LVMerge-available-for-all-labview-versions/idi-p/1507632/page/2#comments.
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: http://automatedenver.com/developer-series-presentation/
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: http://delacor.com/every-developer-needs-a-time-machine/
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 bitly.com/LVscc 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 😉
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:
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
LabVIEW Compare requires some LabVIEW wrapping to make it work with Mercurial. To find the tool, go to the Mercurial user group at NI Forums. Andreas 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”
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.
Conclusion
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
References
- Every Developer Needs a Time Machine blogpost
- Source Code Control Videos at bit.ly/LVscc
- Endigit Configure SourceTree to use LabVIEW Compare blogpost
- Atlassian Tutorial on What is Version Control
- Git User Group at forums.ni.com
- Mercurial User Group at forums.ni.com
- Blog post on choosing Source Code Control tool for binary files. While our conclusion is different for LabVIEW purposes, the majority of the arguments do apply to us as well. Since our binary files are not as large and we do have diff/merge tools, we still think Git or Hg are better tools for LabVIEW development.
Special thanks to Matthias Baudot from StudioBods for helping me with some of the videos on this post.
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.
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,
Fab
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?
Thanks
Callum
Callum,
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.
Regards,
Fab
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.
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 http://delacor.com/category/scc/
If there are any particular topics you would like us to cover, please let us know.
Regards,
Fab
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!
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.
Regards,
Fab
Shoot – no instructions for Sourcetree.
Hi Ryan,
Our friends at Endigit have a blog post on how to configure LVCompare via SourceTree. Check it out at http://endigit.com/2017/11/using-labviews-diff-tool-sourcetree/
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.
Regards,
Fab
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.
https://github.com/smithed/vicompare
Hi Ryan,
Thanks for your comment and for pointing us to the GitHub repo. We will check it out.
Regards,
Fab
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 2.10.0.2.
Any help is greatly appreciated. Thanks!
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 https://git-fork.com/
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 https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7chSAC&l=en-US )
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,
Fab
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.
Regards,
Andrew Casalenuovo
Test Engineer
Moog Inc.
Andrew,
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,
Fab
Fabiola,
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
Hi David,
I have not used TestStand in a while, so I have not ran into the problem of needing two external Diff Tools. This is definitely a request for the Git Fork team. In general their support has been excelent, I will ask them the same question and see if I get any luck on having two external Diff tools.
I did a quickg google search and there are ways via the command line to specify which diff tool you want to use, that is definitely not ideal but you could configure the tool you use most often and then use the command line when comparing for the other tool.
Good luck and sorry I don’t have a better answer for you. Please do share if you find a solution.
Thanks,
Fab
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 https://gitlab.com/gitlab-org/gitlab-foss/-/blob/12-1-stable/vendor/gitignore/LabVIEW.gitignore)
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.
Hi Gabriel,
I haven’t used shared variables in years, so I haven’t experienced this. However, I would think this is similar to deciding when to commit a project or library change.
When I add a new VI to a library, Fork reports both the library AND the project as being changed. I know that the project was not really affected, because updating the library with the new VI is all the change I need to commit to Git.
So, I discard the change for the project and only commit the library.
For this mindfull committing to work, you do need to be making small commits, don’t go a full day without commiting.
Then, it would be easy for you to know that you didn’t touch that VI and you don’t need to commit.
Of course, it always helps to close everything at the end of the day, clear all mass compile cache, and open the project a new and make sure that everything is as you expected to be and that you didn’t miss committing something.
Sorry that I don’t hav ea more useful answer for this issue. Also, if you add an idea to the LabVIEW idea exchange with adding the option to ignore shared variable changes that are not really a change, I would be more than happy to vote for it.
Thanks,
Fab
Hi Fab,
I started to use GIT with labview and now wanted to test Fork with lvcompare and lvmerge.
I face the problem, that lvcompare wants to compare different versions of a vi with the same name (but differnt version)
lvcompare is not capable of comparing vis with the same name and prompts this message:
“Comparing VIs with the same name is not supported.”
Am I missing something? I thought it is the idea of lvcompare and git to compare the same vi from different versions.
Or do you rename each file for the purpose of comparing them?
Best
Malte
Hi Malte,
Are you launching LabVIEW Compare directly from Fork by right-clicking on the VI that you want to compare and using the External diff option?
Hi Fab,
yes exactly. In Fork: Changes of a commit -> right click -> External Diff
Prefences like this:
diff tool: custom
path: C:\Program Files (x86)\National Instruments\Shared\LabVIEW Compare\LVCompare.exe
args: “$LOCAL” “$REMOTE” -nobdpos -nobdcosm
I use labview 2019 (19.0.1) in case that matters?
Best
Malte
Is it just me or are the images not showing anymore on this article?
It’s been fixed a little while ago. Thank you for reporting and sorry for the delay to reply.