"Compare VIs" tools shows no difference in obviously different files

[TeraTech]

I have two controls were flagged as different by my source control. When I use the Compare VIs tool it show no differences. I have all of the Compare check boxes checked - VI Attributes, Front Panel, Position/size changes, Block Diagram Cosmetic Changes and Position/Size Changes.  The files are obviously different be the file sizes are different. What would cause this? Since the source and compiled code are separated, would opening the control in a newer version of LabVIEW cause a change the control's Ctl file? Also, the environment setting for "Do not save automatic changes" is checked. Wouldn't that have prevented the re-compiled control from being saved?

[altenbach]

Well, you can open the two ctl files and look at the source version in the properties. Do they differ? What is the source version for each? (This difference apparently won't show up in the compare tool)

(I assume that you separate compiled code for both the VIs and ctls.)

[TeraTech]

---

@altenbach wrote:"(I assume that you separate compiled code for both the VIs and ctls.) 

---

Ah, the one detail I didn't' include - yes, both have their compiled code separated. The Source Version is the same for both, 17.0, however the Current Revision for the newer one is one greater than the older one. The Revision History is empty. So, as mentioned, something was bumped but it is not obvious what and why.  I could view them in a hex editor, but I don't know what to look for.

[Bob_Schor]

The Compare VI tool looks for functional differences between two graphical representations of LabVIEW code.  I was going to make an analogy to a text-based language, but realized that the analogy would probably "break", as the underlying models are so different!

But VIs are not saved as "pictures" -- indeed, I'm not sure how NI saves the information we draw on our Front Panels, Block Diagrams, and various things like Description, Help text, etc.  Somehow, it gets translated to a Binary Format and saved as a .VI file.

There are numerous things, it seems to me, that can influence the binary, but have no effect on the "functional" VI -- an example would be slightly altering the size of the Block Diagram Window before saving.  The Compare tool is designed to let you know that such a change does not "register" as a functional Change, though it will surely be reflected in the Binary.

So, bottom line, the Compare VI tool can (and does) show two VIs as the same, because they have no functional differences, even though their binaries will differ.  It's a Feature, not a Bug.

Bob Schor

[Intaris]

Just to add to this: LV saves a timestamp (or something similar) in the VI.  Make a copy of two files, they will be binary compatible.  Save both at slightly different times, SVN will think they're different (bacause their Timestamp will be different).

LVCompare does not regard this as a difference in code, only in the code's packaging.  It would actually be nice of LVCompare would simply list "Timestamp changed" as an optional difference (selectable just like BD Cosmetics).  This would at least make the issue more visible (but still ignoring timestamps by default).

[TeraTech]

Thanks for the comments. It is my understanding that SVN does not use time and date stamps but rather a checksum to determine differences. SVN flagged it because the file are different sizes, and thus different contents and different check sums. Is there any way to know why LabVIEW bumped the revision from 17 to 17.1?

[billko]

---

@TeraTech wrote:

Thanks for the comments. It is my understanding that SVN does not use time and date stamps but rather a checksum to determine differences. SVN flagged it because the file are different sizes, and thus different contents and different check sums. Is there any way to know why LabVIEW bumped the revision from 17 to 17.1?

---

Revision of what?  LabVIEW revision?  Probably because the revision got bumped from 17 to 17.1?

[Intaris]

Not SVN, LabVIEW does.  Just saving a file which is unchanged according to SVN will make it changed.  This is correct from an SVN point of view, the binary content has changed.

[TeraTech]

---

@billko wrote:

---

@TeraTech wrote:

Thanks for the comments. It is my understanding that SVN does not use time and date stamps but rather a checksum to determine differences. SVN flagged it because the file are different sizes, and thus different contents and different check sums. Is there any way to know why LabVIEW bumped the revision from 17 to 17.1?

---

Revision of what?  LabVIEW revision?  Probably because the revision got bumped from 17 to 17.1?

---

Every VI has its own revision number. In this case the revision was bumped from 17 to 17.1 (not to be confused with the LabVIEW Version 17).  Because that revision number is contained in the vi, SVN saw it as a difference and flagged it. So that is my question, why did LV bump the VI's revision? The Compare VI tool found nothing.