Comments on: When to commit changed VIs caused by type definition changes

By: Jim Kring

Jim Kring — Thu, 20 Nov 2008 21:14:19 +0000

Rob: Thanks for sharing you perspective and experience on this. It’s nice to know that we’re all converging on a similar process. Hopefully NI can help improve LabVIEW to make this sort of workflow easier.

By: Rob Calhoun

Rob Calhoun — Thu, 20 Nov 2008 19:59:07 +0000

The recompile only changes are indeed a pain when using source-code control. It would be nice if LabView had better tools for identifying the difference between real “source code” (fp/block diagram) changes and “object code” changes.

We follow pretty much what Jim suggests: first we start with a clean working copy. Then we edit the typedef, preferably with everything in memory because LabView seems less prone to making substitution errors that way. Save and close it. Then we fix all the broken VIs, saving each as we go. Then we commit all of the saved routines together—these are all real changes and get a real commit message. Then we save everything else that changed with the special phrase “recompile only”. In our case, this phase has to appear verbatim somewhere in the commit message. It is a hint to our merge tool that the changes should be ignored when merging changes from one branch to another.

-Rob Calhoun

By: Leif Suonvieri

Leif Suonvieri — Tue, 11 Nov 2008 12:39:42 +0000

Danny: I’ve made a little utility that uses the Subversion command line client and LVDiff, and I set the compare options to include “VI attributes”, “Front Panel” and “Block Diagram” and the others to false. This is not bullet proof but it has worked for me so far. If someone knows a better way to discover a recompile I’d be happy to hear about it…

By: Danny Thomson

Danny Thomson — Tue, 11 Nov 2008 08:52:02 +0000

Leif, that sounds a great little program, would you mind telling me how you can tell that the only change is a recompile? I tried to do something similar using the VI Modification Bitset but I could not fine any info about what the value’s meant other than the VI had unsaved changes.

Plus I very strongly agree with your comment.

Jim you reply to Dale regarding who should fix a broken VI if not in your area of responsibility is I suspect a whole new blog entry in the making if you have a Monolithic approach, then anything broken by your change IS your responsibility, in a modular approch it is not such a simple question

By: Leif Suonvieri

Leif Suonvieri — Tue, 11 Nov 2008 07:30:47 +0000

Unfortunately, National Instruments still sticks to the annoying “Code and compiled binary in the same file” – scheme.
I suggest that everyone who reads this submits a feature request to NI to let them know that this has to be changed.

Anyway, I handle this problem the same way as Jim and in addition I use a little program that recursively shows changed files which only contains recompiles, and let me choose which ones to revert. This makes it easier to handle the result of accidenically clicking the “Save-All”-button.

By: Jim Kring

Jim Kring — Mon, 10 Nov 2008 21:13:36 +0000

Dale: You bring up a good point -- an issue worth careful consideration. In the case where you write your LabVIEW code so that it breaks when you change an enum, then you'll know that you need to modify the broken case structure. One question is: if the VI that's now broken is not within your area of responsibility, should you fix it or notify the owner of the code so that they can fix it? Another important question is: are the changes to a VI in memory (when the type definition changes) the same as would occur if the VI were loaded into memory after the changes occur. This will impact the decision of whether to save the changed VIs (right when the typedef is changed) or to wait until later.

By: Dale Tucker

Dale Tucker — Mon, 10 Nov 2008 19:56:37 +0000

This is a good suggestion for recompiles, but the example (type def changes) may not always be innocent recompiles. Some type def changes can have “real” changes within the code. An obvious example is an enum typ def defining states within a state machine. If the state is redefined, the code within the case structure handling the case will not be updated. Additionally a vi will break if the case structure handling the case does not declare a default state, (I know never happens) when states are added. Another example is when your type def is used as an input parameter to a strictly typed Call By Reference Node. Any changes to the type def will require remapping the call. Good suggestion for documenting simple rebuilds in your version tracking effort, but type defs may have wider implications.

By: Jim Kring

Jim Kring — Mon, 10 Nov 2008 17:46:38 +0000

Danny: That’s a great point: changing VI connector panes can impact calling VIs in a way that’s identical to how changes in a type definition will affect callers.

Todd: Great, let’s do it! It’s only Monday, so you’ve got the whole week to work on it

By: Todd Sierer

Todd Sierer — Mon, 10 Nov 2008 17:27:42 +0000

Another great post! We need to get your blog content on our site like we’ve done with Mike A.

By: Danny Thomson

Danny Thomson — Mon, 10 Nov 2008 10:37:02 +0000

I have seen this type of solution talked about in both the NI and Lava forums, and would take it even further than just type def changes. I would propose a similar approach to the situation whereby one or two Vi in the heart of a project are change and cause many file to recompile. To be able to differentiate between the files you have actually edited for something and those that have “auto” change due to LabVIEW being LabVIEW is a very important point for a configuration control point of view.