Allow changing branches in Source Code Control without having to close project or exit LabVIEW

[Taggart]

After working with text-based languages recently, I've become more aware of a very painful flaw in the LabVIEW IDE.

First of all, as software engineer, I like to perform experiments. Make a small change, test it. If it doesn't work, then just use Git to roll back the changes. I've been doing this for years, and with LabVIEW it has been fairly painful. Until recently I didn't realize there was a better way.

Why is it painful? Everytime I use Git to check out a different branch or roll things back, I am forced to close LabVIEW or at least close the project so that LabVIEW detects and loads the new code from disk instead of whatever it has in memory. I lived with that for years because I didn't know any better.

Enter text-based programming and IDEs: VSCode, PyCharm, probably any other modern IDE. I try an experiment, it doesn't work. I roll the changes back in Git and guess what? I don't have to open and close anything! The IDE just automatically detects the file has changed and loads the new file!

When is LabVIEW going to get with the times?

[felipefoz]

I am in doubt about the "having to close the project": changing branches should reload instantly the new project structure without closing it? If that is the idea, then it is a really good one.

Meanwhile, a workaround with a git post-checkout script to reload the project could be done, eventually revert VIs still in memory, unless closing-loading time is not acceptable.

[fefepeto_kb]

I don't say it wouldn't be useful, but I would like to highlight a very different aspect of the text based languages and LabVIEW:

LabVIEW stores the compiled code in a cache and loads the compiled code together with the source code.

Therefore, when we are talking about changing a branch we are also talking about recompiling the changed piece of code, then relinking the compiled code with all the dependent pieces. It gets especially tedious when the code is inlined.

Opening the project, and all the files inside takes care of this compilation process.

In that regard I'd like to mention that opening LabVIEW projects where some code modules have been moved around is a pain. It often times searches for the code and fails to identify the correct ones. It gets even worse if LabVIEW finds more than one VI and starts loading the "missing" files from two separate paths. I think these issues shall be solved before heading into a branch changing maneuver.

[stephen.butler]

I can't understate how important this is for modernizing LabVIEW for git workflows. When I pull or change branches with git using an IDE like VS Code or any other the text files are all just automatically updated to what was changed on disk. The inability to do that with VIs is incredibly painful and slows work down considerably.

This would be a huge modernization improvement! This is a major feature for improving the scale of LabVIEW projects!