Why not split VI in two files?

[LeifS]

When trying to use a version control system that doesn't rely on file locking together with LabVIEW, you will sooner or later run into trouble with automatic recompiles.

In my case I'm using Subversion (TortoiseSVN) as my VCS and I'm very pleased with it's functionality.

But...

National Instruments have somewhere in the past decided to mix the source with the binary into the same file

That results in TortoiseSVN flagging the VI as "locally changed" when the only change was a automatic recompile that was accidently saved.

LabVIEW has a setting for not saving recompiles if the VI is locked (read-only), but this requires me to start using Subversion in "lock-modify-unlock" mode with it's disadvantages.

Instead I'm suggesting NI to split the VI into two parts:

 1. The .VI  file that contains only the "source code"

 2.  A new .VIC  file that contains the compiled code.

This way I could tell TortoiseSVN to ignore all .VIC files and continue to work with Subversion in "copy-modify-merge" mode.

Now isn't this a great idea for the next upcoming LabVIEW version ???

/LeifS

[tst]

The idea itself is good, but it would not come as a shock to NI. They have heard it before. That said, a visit to the Product Suggestion Center might be helpful.

Incidentally, I don't use that option, since I prefer committing the recompiled VIs, but the help does not mention that this option is only for read-only or locked VIs. This is only implied because of the indentation the checkbox has. 

I did try it now and it didn't seem to work, but that might be a bug (e.g. maybe I needed to restart LabVIEW). I suggest you try checking it to see if it works and if not, submitting a bug report to NI, as this is something which is more likely to be changed soon than the change in the file format.