Version control management / backup for LabVIEW

[crossrulz]

---

@Intaris wrote:
I strongly disagree with the sentiment of this post. Is Git most popular? Yes. Is it the best? Depends on the job and the person. There is no single "best" SCC because people and projects are incredibly diverse. You may have found your favourite, but please just accept that not everybody is going to be the same opinion.

---

I never said Git was my favorite.  Nor did I say it was the best.  All I stated is that it is the main tool of choice for software development.  I do like SVN, it works extremely well.  I would still be using it if I didn't have a corporate mandate to use Git.

[matys]

---

@BertMcMahan wrote:

...

---

Since LV2022 Q3 (the version OP is using), LVCompare is available in all editions.

(https://www.ni.com/docs/en-US/bundle/upgrading-labview/page/labview-2022q3-changes.html)

---

Good to know. Thanks for the update.

[Frozen]

---

@crossrulz wrote:

---

... I do like SVN, it works extremely well.  I would still be using it if I didn't have a corporate mandate to use Git.

---

Same goes for me.

I would prefer to be using SVN. It is a better choice for LabVIEW IMHO.

[Andrey_Dmitriev]

---

@Frozen wrote:

---

@crossrulz wrote:

---

... I do like SVN, it works extremely well.  I would still be using it if I didn't have a corporate mandate to use Git.

---

Same goes for me.

I would prefer to be using SVN. It is a better choice for LabVIEW IMHO.

---

For me the better choise was (you will be probably smiling... — the Microsoft Sourcre Safe). Still using it for some private project and love how its integrated in LabVIEW IDE, small marks show the status, checkin/chechout from project:

And everything works here, history, diff, etc:

Nowadays working with Git/GitHub/TFS, etc (as dictated by company policies), tried different adapters, but never ever was able to get such convenient integration (or it was too buggy, etc). And in the past I've using Links in MS VSS repository (for PlugIns-oriented design), this feature was removed in TFS, and in Git something similar is possible but not so convenient and complicated to setup.

[Sebastian.Weber]

May be some reasons:

Labview likes to alter "random" files all over the project, though you did not touch them:

• VIs by default contain compiled code, so if LV thinks it has to recompile a VI, the file is altered - though there's absolutely no difference in code or settings. So, you want to separate compiled code from the VIs, wich can be done in the settings in the VI or in the project. There's also a global LV setting, which affects new files, only.
• If you edit a typedef in C, source code files using the typedef are not updated automatically. In LV, all VIs using the typedef are updated.
• Often, files are altered for absolutely unknown reasons
• ...

Now, merging altered files is a pain in LV. The compare tool is somewhat slow and not always shows the differences clearly. Often, there are no changes at all, and in case of class method VIs, the temporary file to be compared to the local file claims to be part of the library, but isn't - leading to MANY differenced, since the VI is broken etc.

Now, the concept of git is to use branches a lot, there's even more than one repository: You can work on a local repository, and send everything to the upstream repository once you are done with the task. At the end, lots of files have to be merged. Though this is a powerful concept , it is a pain in the ass with LV. It's better to use a more straight aproach and stay very close to the main branch/repository. And then, you can stay e.g. with SVN.

Ah, something important:

VIs and CTRLs are binary files - a version control system will not try to merge them, you have to decide which version to use upon a conflict. But project, library and class files are XML files, and a version control system tries to merge them. The problem is that LV stores binary data in a row inside the XML file. If two programmers changed something leading to different binary content, a merging algorithm will think that the old row was deleted, but two new rows were added. This confuses labview, which expects exactly one row of binary data.

Therefore, do not allow your version control system to merge those files. For example, tell SVN that this files are binary ones.

[softball]

Hi

Now we have revived VSS from its current pretty dead state, it may also be helpful to point to a paper prepared by NI Sales Staff in 2013 or so :

https://www.ieee.li/pdf/viewgraphs/essentials_of_file_management_with_labview.pdf

50 colorful pages about proper file management in LabVIEW including SCC.

Regards

[Quiztus2]

Thanks for sharing the slides. Imagine LV is going open source. Hell would break over us.

I once made the naive approach to have some libraries in a dev branch and a released version installed on the same machine. I gave my best but finally gave up. It was a huge mess of paths pointing in every direction. Version control is the biggest pain point for me so far and I am a single developer. This is actually why I dont recommend learning LV to my colleagues, since I am afraid of having to merge our mess then. 

[BrenS]

Interesting Thanks!

[BrenS]

Thanks this is useful to have!