tortoise says file changed, but diff says the file is the same

[DLMC]

Windows 7 Enterprise

Labview 2010

Teststand 4.2

Several different computer configurations

I am trying to make sure that several systems with the same LV code are all in sync and up to date before applying my changes.  I am updating code that was created and maintained by someone else for several years..  I have code on several manufacturing computers and on a lab development computer. 

All machines are the same Windows version (Win 7 Enterprise), all machines are running the same LV revision - LV 2010.

Yes, it is old stuff, updating everything would require us to hire an entire department skilled with Acrobat, Windows Office, Active X, Oracle, Labview and Teststand - and a whole lot of time. .I'll deal with upgrading when I get everything to agree.  The cluster caused by two+ years of pandemic has been extreme.

On my development computer

The dev computer is fully in sync with the SVN repo, according to tortoise SVN, with green checks.

However, in many cases, the Windows date stamp is different than the tortoise SVN "show log" entry date stamp.The LV diff utility says that they are the same.

On the production computers

tortoise SVN has (red !) on many files.

The vast majority of the "different" files have the exact same Windows date stamps, down to the minute.

Sometimes, but not always, tortoise SVN "check for modifications" says that the file is different.

Labview diff tools say that the vi's are identical

Often, just running the LV diff tool, when I close the diff, LV asks if I want to save changes - I didn't make any changes, why does it do this?

There are hundreds of files doing this.  It would take me months to look at each file (nearly impossible, actually) or revert a file and run the sequence files to see if it works.

What is the real truth?  My OCD tendencies want it all to be absolutely correct and aligned on all machines!  Am I destined for disappointment?

be well,

DLC

[Kyle97330]

---

@DLMC wrote:

My OCD tendencies want it all to be absolutely correct and aligned on all machines!  Am I destined for disappointment?

---

Short answer: Yes. Disappointment.

Long answer:

Unlike a "traditional" coding language like C, a "VI" file includes not only the G code needed to store the front panel and block diagram, it also contains the compiled code for the PC to run the VI, unless you turn off that option.  Turning off that option was only available starting in LV 2010, plus it doesn't work well with TestStand, so it's unlikely that your predecessor used that option.  Code that is exactly the same will compile and save to this section of the VI slightly differently each time.

One thing that's common to do with LabVIEW code called by TestStand on different PCs is called a "Mass compile".  If there is the smallest difference between one PC's environment and another environment, this will re-save the VI with a slightly different compiled code section causing it to look like it's changed to Tortoise, and doing this to potentially hundreds of VIs within the same minute.

The only thing I can think to suggest to you is that you could do some scripting to check all of the VIs on a PC for changes, using LabVIEW for the scripting since any other tool couldn't manage to compare the LabVIEW code while ignoring the compiled code differences.  It would have to go something like this:

1. Duplicate the repo from SVN on the PC in a different directory

2. Create and run a script to rename all of the files in that duplicated directory (LabVIEW can't have 2 files of the same name in memory unless they belong to different libraries, which you can't do without changing the files...).  Make it something like adding "_DUP" to the end of each file so you can tell what the original name was easily.

3. Create and run a script that compares each changed file with its original.  This VI should be included in LabVIEW that can do all of the comparison for you:

\vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi

4. For every pair of VIs that doesn't return as "Same?", create a log file entry to go back and review that manually later with the Diff tool you are already using.

I'm leaving out a lot of the details on the "Create and run a script" part, here...

[DLMC]

"

One thing that's common to do with LabVIEW code called by TestStand on different PCs is called a "Mass compile".  If there is the smallest difference between one PC's environment and another environment, this will re-save the VI with a slightly different compiled code section causing it to look like it's changed to Tortoise, and doing this to potentially hundreds of VIs within the same minute.

"

Crap, did I break running code on the production machines by reverting files I looked at that diff'd as unchanged?  Since practically all of my production computers are different from the development machine and even each other, this sounds like there is no hope of knowing at a glance, when a local file has been changed.

Wow,

DLC

[Kyle97330]

Probably not?

I am not using TestStand now, but I did a few years back.  My experience was that sometimes this happens:

1. TestStand runs, returns a nonsensical error

2. Mass compile everything in LabVIEW

3. TestStand runs again, no problem

While it's possible that you did "break" something the chance is low to begin with, and even if you did it will be the "safe" kind of break, where it's an obvious immediate error.  This is opposed to the "unsafe" kind of break, where it all looks like it runs fine but then does something sinister like skipping steps secretly or returning inaccurate test results.

[billko]

Do you have the "Separate source from compiled code" (or something like that; I think they changed the exact wording a few times) check box checked?  This moves the compiled code to a cache so that things like what you've just described happen far less often, if they even happen at all.

[avogadro5]

Unfortunately even with compiled code separated there is still the possibility of other changes not showing up. One I'm aware of is persistent tags as returned from the Get Tag method.

That said, separating compiled code dramatically reduces the number of "fake" changes in source control. They're also not fundamentally incompatible with TestStand, what they're really incompatible with is the runtime engine.

[Bob_Schor]

I've been using TortoiseSVN and LabVIEW together for more than a decade.  I think I can explain what you are seeing and suggest ways to "understand" and/or "mitigate" this behavior.

The first thing to understand is what does it mean for a file to be "different".  For TortoiseSVN, this means that some aspect of the file has changed.  This can include the timestamp of the file (caused by opening and saving the file, or otherwise altering its timestamp, even if the file contents itself are unchanged), or some (relatively) trivial aspect of the file has been modified (such as opening and saving the file, even without altering its timestamp, but altering its LabVIEW Version number, though no tangible component of the file has been modified.  A third way for this to happen is if the compiled file is not separated from the source code, as this can "force a change" even when the source code remains the same.

For LabVIEW, however, "different" can have more subtle meanings.  For example, when one does a LabVIEW compare of VIs, one usually considers files "identical" if they differ only in Front Panel (or Block Diagram) object size or position, or "appearance" (I'm not 100% certain I fully understand what this means).  It does, however, detect frank wiring changes or differing objects on FP or BD.

For SVN, however, files are different if they aren't byte-for-byte identical.  So if you open a Project, open some VIs, make a change, save anything, open the VI again, and change it back, you will create a difference that SVN will "notice" (although the Project "objectively" is identical).  SImilarly, just opening files in a Project without any changes, and closing the Project and doing a "Save" (as opposed to "Don't Save") will create a changed Project File, which triggers a Subversion "change".

What I try to do (not always as diligently as I'd like to be) is to work on a small section of code, test, and Commit (with Change notice) frequently.  If I "get ahead of myself" and have, say, a dozen "changed VIs" in a Project, I might do a "compare everything to everything", notice which differences are "real" (i.e. the code really did change, so I should pay attention to "this VI" and be sure the new version actually works), whereas if I just changed the appearance of the VI, LV Compare will say there's no difference, and I can commit the new version safely.

The bottom line is that Tortoise is looking at the "bits" in the file, while LV Compare is looking at the aspects of the LabVIEW code described by the file (where "moving a wire up 5 pixels" results in a physically different file, but functionally identical code).  The safest practice, in my experience, is to "ask to Commit early", ensure that the files marked "different" are files you expect to be different, and if you see files that you think "should be the same" but are marked "different", use LV Compare to verity that LabVIEW thinks they are "functionally identical", and if they are, go ahead a Commit them to get the "polished, edited" version with identical functionality into the updated version.

Bob Schor

[DLMC]

Well, darn.

This kind of means that SVN will almost never agree with the code on all of the production machines, making me second guess every time I see a (!) in a folder.  Better make sure I write good comments in the commits.  As soon as I get all my changes installed and everything working I will at least have a known starting point.  Making sure that there aren't any localized changes that are on the machines will be a slog - there are hundreds of vi's and two years of "support" without the original support team in house to clean up.

Well, I like a challenge...

Thanks all.

be well,

DLC

[Mark_Yedinak]

Not necessarily true. If the production machines have the full LabVIEW install then you can use the option to separate the compiled code from the source. Once done and you update all of the production machines things will sync up properly. If however you are using the runtime engine with TestStand then you would need to include the compiled code with the source and trivial changes can cause code to recompile and appear different to SVN.

[DLMC]

Yup, running Teststand, so, apparently all bets could be off.  🙂

be well,