Large scale development using LabVIEW is easy to manage thanks to seamless interaction with third-party software tools that enforce check-in and check-out policies among large teams of developers. However, existing methods for comparing and merging code segments were previously unable to process graphical LabVIEW code, thereby requiring you to manually sorting through modifications in order to determine and combine changes.
You can use VI Merge both automatically and interactively. The same functionality available within LabVIEW is exposed through an external executable that is intended for use with source code control applications.
Comparison of code is performed in VI Merge based upon an original, un-modified copy of the VI, which is considered the Base VI. VI Merge is intended for use when modifications to this base copy are made by multiple individuals and saved separately of one another. These two modified copies are labeled Their VI and Your VI in the Merge VIs dialog box. All three copies of code are provided to VI Merge, which then compares and merges all non-conflicting modifications.
Enforcing the checking in and out of code is intended to prevent multiple developers from needlessly working on the same segment of code, but there are multiple scenarios in which code can be taken offline and outside the control of management software. When this occurs, problems can arise as a result of conflicting modifications that are saved to multiple locations and VI Merge is the only tool capable of recombining these changes. Smaller development projects that do not use source code control software can implement parallel development as a method for increasing efficiency.
Consider a scenario in which multiple cases of a case structure are to be populated with different code, illustrated in the image below. The base VI contains the empty structure with all the appropriate inputs and outputs wired as necessary. This incomplete VI is then distributed among multiple developers to fill in code for the various cases and eventually recombined in an automated fashion through the use of VI Merge.
Note: The run arrow is broken because the outputs of the case structure are not connected to anything yet. This is the Base VI, which multiple developers will modify.
If permissions are adjusted to allow multiple developers to modify this file simultaneously, they can each work on separate cases of this structure, thereby combining their efforts. Consider the creation of code in parallel by separate developers for two cases of the structure illustrated in the previous image, Basic Function Generator, and Sine Waveform. The developers can save the two copies of the original file, illustrated in the following image, to new, separate locations and according to the Merge VIs dialog box, one is Your VI, and the other is Their VI.
Note: Because LabVIEW cannot load two VIs with the same name, you must rename the VIs you want to merge.
The Merge VIs dialog box prompts users to specify the location of all three files. Calling the executable from the command line simply requires the specification of a few parameters including the location of the three copies of the VI. Either implementation yields the same result given that no conflicts exist.
After specifying the location of the three copies of code and running the utility, LabVIEW displays a merged copy of the VI as well as the original three pieces of code and enumerates each merge operation that LabVIEW performed. You can explore these changes and revert to the base copy, or save the merged VI. If conflicts arise as a result of the merge process, the Merge dialog box appears prompting the you to select the modification you want in represented in the merged VI from the base VI, the VI designated as Your VI, or the VI designated as Their VI.
The Merge dialog box provides you with the flexibility to either accept the merger LabVIEW creates of the two pieces of code, or revert any individual modifications. Stepping through the changes by clicking on them highlights the change on the front panel or block diagram of the merged VI.
Conflicts can arise during a merger if two individuals changed objects within the VI in a manner that they cannot co-exist after merging. For example, if one developer creates code the increases the size of a front panel object while another developer creates code that decreases the size of the same front panel object, when you merge the VIs, VI Merge displays an unresolved conflict and prompts you to select one change or the other.
Ultimately, VI Merge avoids inefficient use of development resources by automating a process that can otherwise be tedious and very time consuming. Errors and conflicts that break code during parallel development can be avoided through proper use of this tool in combination with a defined source code management process.