07-03-2026 07:47 AM
I found a behaviour of LVCompare today which was causing me some headaches.
I have a source distribution "Export" which I bind to another repo via SVN:Externals
Due to recreating all of the files each time, even when they do not change I have a VI which calls LVCompare on all of the files listed as changed (all of them essentially). Those which report NO changes according to LVCompare are simply reverted so that I'm not re-committing essentially unchanged files all the time.
So far so good, this has worked for some time.
Recently, due to a mistake of mine, I had erroneously committed a file which linked to a file from Outside the Export folder (event though that file is present within the folder - thus causing a conflict). Something I go to some lengths to prevent. The export should always be self-contained. No problem I thought, I fixed the source, created a new Export and ran my "Autorevert" code and committed.
Conflict still there. I searched for a bit, eventually tracked down the problem to be the following:
When comparing two VIs where only the path of a typedef being used is the change (relative path change), this is NOT flagged as being a change. As such, LVCompare was telling me they were identical and so I kept reverting to the conflicted files.
So Although I'm tempted to call this a bug, I'll first ask: Is this a bug? Should LVCompare not react to a change in the callers path and notify based on that? At least as an option?