When to commit changed VIs caused by type definition changes

Posted on Monday 10 November 2008

In LabVIEW, whenever you change a TypeDef (type definition) any VIs that use the TypeDef will require recompiling and need to be saved.  This presents a problem for developers working on a large project with other developers who might be working on code that “feels” the effects of the changed TypeDef.

So, how do you deal with all the unsaved VIs in your project that are not in an area that you “own”?  If you don’t save them, then LabVIEW will keep bugging you to save the VIs.  And, sometimes your LabVIEW code will even run slower until you save all your VIs.  But, if you do save these VIs, then it’s hard to tell which VIs that you’ve saved have “real” changes and not just recompile changes.  And, if you commit all the changed VIs, then you might increase the likelihood of creating a conflict with other developers.

Here’s a good process you can follow to deal with this issue:

  1. First, commit your real changes, separate from the recompile changes.  This will give you a specific svn revision (changeset) associated with your real changes.
  2. Then, save all the recompiled VIs and commit them.  For your commit log message, use “Recompiled due to typedef changes” (or similar).  This will indicate to other developers that the changes can be ignored, in the event that this revision conflicts with their own changes.
  3. Finally, Alert your team that you have committed a recompile of code (with no real changes).  They can then easily resolve any conflicts, because they know that the commit contains no real changes.

Now, if you know that other team members are actively working on the code and you don’t want to inconvenience them with having to deal with conflicts, you can defer the recompile until a later time or schedule a time for the recompile with your team.

Note: Even if you use a locking system (such as svn locks or a check-in/check-out SCC model) where files for which you don’t have the lock are read-only, you will still have the slow-down issue and will periodically want to do save all to recompile.

Have you had this issue?  What solution or process do you use?

10 Comments for 'When to commit changed VIs caused by type definition changes'

    Danny Thomson
    November 10, 2008 | 2:37 am

    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.

    Todd Sierer
    November 10, 2008 | 9:27 am

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

    November 10, 2008 | 9:46 am

    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 ;)

    Dale Tucker
    November 10, 2008 | 11:56 am

    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.

    November 10, 2008 | 1:13 pm

    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.

    Leif Suonvieri
    November 10, 2008 | 11:30 pm

    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.

    Danny Thomson
    November 11, 2008 | 12:52 am

    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

    Leif Suonvieri
    November 11, 2008 | 4:39 am

    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…

    Rob Calhoun
    November 20, 2008 | 11:59 am

    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

    November 20, 2008 | 1:14 pm

    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.

Leave a comment



Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.

RSS feed for comments on this post |


Bad Behavior has blocked 772 access attempts in the last 7 days.