Search the Community

I use SVN for version control in my project and am often faced with many conflicted VIs that must be dealt with. I have found that frequently, the changes causing these conflicts are not "real" changes (for example, a wire was moved or a typedef for a cluster control was changed). So, I am trying to create a tool that queries my project directory for any VIs that have conflicts, and running the VI Comparison tool with only non-cosmetic changes enabled to automatically find VIs that don't have any "real" changes and marked the conflicts as resolved. I would like to build the tool into a .exe because I would like to be able to run this tool from the command-line so that I can create a right-click menu item in my Windows environment to easily run the tool from any folder containing conflicted files. I found vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi which performs the comparison operation, allows me to specify which types of changes to detect, and returns if there are differences. This is exactly what I need and it works perfectly in the development environment. However, when I build my tool to a .exe file, I get a LabVIEW error with the following description: Error 1574 occurred at Open VI Reference in SCCSup Compare Two VIs.vi->Resolve False Conflicts.vi Possible reason(s): LabVIEW: (Hex 0x626) Cannot open a file with separated compiled code in the LabVIEW Run-Time Engine. An error occurred loading VI 'my.vi'. LabVIEW load error code 59: The source file's compiled code has been separated, and this version of LabVIEW does not have access to separated Where my.vi is the path to the VI that it is attempting to compare. All of the VIs in my project have "Separate compiled code" enabled since I use version control on them, therefore turning it off it not an option. Is there any way to get around this issue?

Has anyone actually configured Git to work with LVCompare or LVMerge? (I've seen some threads on various boards saying it "should be something like" <x>, but it isn't quite <x> and I haven't found anywhere that someone has actually described it successfully.) Notes: I know how to configure TortoiseSVN to work with LVCompare and LVMerge. My new employer is moving to Git (some good, some bad in that, in my opinion, but that is another topic). I have been using Git for a few months now with reasonable success and decided I should try to set up graphical differencing. [OK, in practice I've rarely used graphical differencing for any practical purpose, and graphical merging probably never for any actual code.] Anyway, I think I've learned some things trying to figure out how to get this to work--but I don't have it working yet. I use the Atlassian SourceTree client at present (and sometimes the shell). For the purposes of this discussion it might be more helpful to share the relevant text in the .gitconfig file (and any associated scripts, if necessary). As others have mentioned, Git itself (SourceTree similarly) does not distinguish which diff tool to call according to the file extension. This seems like it could be a significant drawback. What I have tried: I added this (and variants of it) to my .gitconfig file: [difftool "LVCompare"] path = C:Program Files (x86)National InstrumentsSharedLabVIEW CompareLVCompare.exe keepBackup = false trustExitCode = false[difftool "LVCompare"] cmd = "C:Program Files (x86)National InstrumentsSharedLabVIEW CompareLVCompare.exe" "$LOCAL" "$REMOTE"[diff] tool = LVCompare SourceTree reports errors on start-up, so don't use this! Lol! Maybe I need to add a script, too. I'm not sure that I'm really all that close, honestly. [bigger question: Why is this difficult in the first place?]

I am getting started with using TFS for source code control with LabVIEW. I am using TFS 2013 and LabVIEW 2013. I have a few questions: What is the best way to move files from one project folder to another? The "move on disk" doesn't appear to be a good option. I want to be able to make file moves if needed and don't want my project to end up blowing up with conflicts. It appears that once source control is set up in LabVIEW that all check in/check out operations need to happen in LabVIEW and not TFS or windows explorer. Correct? I just noticed the "Include callers when checking out files" option. I am assuming that is probably a good option to select so that they callers will be modified and saved as needed. Does having files set up as auto populating have any negative effects on how source control is done? Unfortunately it appears that we are stuck using TFS for source control since the firmware developers are using it and it is a company application now. Any help or guidance you can provide would be appreciated. Thanks. Joe

Here is the set-up: I have a component project library (StepperMotor.lvlib) that I have moved to the userlib in order to facilitate reuse over multiple projects. Within the library I have 1) a strict typedef (StepperMotor.ctl) cluster that contains a numeric control for expressing the maximum output step rate. 2) the StepperMotor.lvclass, an abstract class that contains effectively virtual methods (they do nothing but wire inputs to outputs) and LabVIEW-generated accessor methods for the two items in the class private data. This is LabVIEW 2013 SP1 on Windows 8.1. OK, so I start with everything clean (git status reports clean, LabVIEW opens and closes the library without prompting for changes). 1) Then I open the StepperMotor.ctl directly from Windows Explorer (hence not opening the library), change the range of the numeric from 2 kHz to 4 kHz, and save it. 2) Then I open the library, make no further changes, and attempt to close the library. LabVIEW correctly prompts me to save changes. I opt to close the project without saving changes, however. 3) Next I discard the change to StepperMotor.ctl using git. (I have been using Discard in SourceTree, or a git reset --hard command.) Then git status returns a clean status. 4) I open the project and attempt to close it. Since I have reverted all changes, LabVIEW does not prompt to save changes. So far, so good. This is expected behavior. Now, I repeat the steps, except that in step 1) I open the library first, open the typedef control from the project, make the same change, save the control (without applying the changes), and close the project (without saving). 2) is the same as above (OK). 3) is the same as above. Again, git status shows me everything is clean. 4) I perform the same action as above, but this time LabVIEW prompts me to save all the accessor methods on the class, citing a changed typedef (even though if I open the typedef the range is indeed back to its original value). This is unexpected behavior. Worse yet, even if I perform a git reset --hard and verify with a git status that everything is clean, if I open and immediately attempt to close the project, LabVIEW still prompts to save, citing "Type Definition modified". This is indeed problematic. (Further note: If I let LabVIEW save the changes, git status still shows clean, and LabVIEW opens and closes the project without prompts.)