The Software Engineering lifecycle typically involves some stage at which source code must be modified, whether it is during the development stage or during maintenance stage. This article is an introduction to some of the version/revision control tools available in LabVIEW and using Source Code Control providers to track and manage changes made to VIs and applications built in LabVIEW.
LabVIEW includes a built-in Revision History feature for VIs called VI Revision History that can be suitable for smaller development teams or projects. This built-in Revision History feature allows you to:
The Revision Number of a VI starts at zero and increments whenever changes to the VI are saved. In addition, you can configure LabVIEW to force users to enter comments each time a VI is saved or closed after changes are made to it.
The revision number in VI Revision History lets you quickly keep track of when and how many changes were made to a VI during its lifecycle. If used properly in conjunction with comments, it can also let you easily keep track of what changes were made to a VI over several revisions.
For more information on VI Revision Numbers, refer to the section titled Revision Numbers in LabVIEW Help: Setting up the VI Revision History
You can access the Revision History of a VI from the VI Properties dialog of a VI:
For help on the Revision History dialog, refer to: LabVIEW Help: History Window
By default, LabVIEW will never prompt users to comment changes made to a VI, but will automatically increment the Revision Number when changes to a VI are saved.
This can lead to situations of VIs being modified significantly without any documentation on what was changed. You can enforce documentation of changes to VIs by:
To set this behavior for the current VI:
To set this behavior for every VI:
For more information regarding the Revision History Options, refer to LabVIEW Help: Setting up the VI Revision History
You can also programmatically access the Revision History of a VI using the LabVIEW ActiveX server – VI Server. The VI class of VI Server has methods and properties that allow you to access the Revision History and set its properties using Invoke Nodes and Property Nodes.
For information regarding using Property Nodes and Invoke Nodes, refer to LabVIEW Help: Creating Property Nodes and Invoke Nodes.
For information regarding the Revision History properties and methods available, refer to LabVIEW Help: VI Properties and LabVIEW Help: VI Methods.
For example, the following screenshot shows a VI that takes the path to another VI as an input. First it opens a reference to the VI and clears the history of the VI and resets its Revision Number. Then it sets the Revision Number of the VI to 31 and finally closes the reference to the VI.
The LabVIEW Revision History feature is handy for keeping track of changes made to VIs, however its features are limited. For instance, The Revision History feature will not let you revert back to older versions of VIs not does it prevent multiple developers from accessing/modifying the same VI simultaneously. For advanced features required for large application development particularly in a team setting, NI recommends using 3rd party Source Code Control software for Revision Control.
Most large application development is done in teams of developers or engineers, each working on portions of the code-base simultaneously. This introduces several potential issues that need to be addressed such as tracking/managing changes to code as well as providing a centralized location for the latest versions of code.
Source Code Control (also called Revision Control or Source Code Management) software provides a way to share and control access to source code in an effort to mitigate the issues that arise from group development. Source Code Control software tracks changes to code using version/revision numbers and maintains a history of changes made to the code by keeping a copy of each revision of the code. Revisions can be compared with older versions, older versions can be restored and changes from various sources can be merged into a single file.
LabVIEW provides integration with industry-standard source control providers like Microsoft Visual SourceSafe, Perforce, Rational ClearCase, PVCS Version Manager, MKS Source Integrity and free, open-source software like CVS. This integration provides access to functionality in third-party source control providers within the LabVIEW environment.
For more information on the various Source Control providers that can be integrated by LabVIEW, refer to Selecting a Source Control Provider in LabVIEW Help Documentation.
If you have a VI that is part of a Source Code Control depot, you can check the current revision number of the VI from LabVIEW:
The dialog that appears will vary depending on the Source Code Control provider, but will typically contain information regarding the current revision number as well as the latest version available in the depot. For instance, the following screenshot shows a VI that is in its 4th revision for a system configured to use Perforce as its Source Code Control provider:
LabVIEW provides several VIs that allow you to access your Source Code Control provider programmatically. These VIs allow you to programmatically add files to Source Control, check-in and check-out files, compare files and view their history. Note that these VIs require you to integrate LabVIEW with a 3rd party Source Code Control provider before you can use them.
The Source Control VIs are available from the Functions»Connectivity»Source Control palette in the block diagram. For help on the Source Control VIs, refer to LabVIEW Help: Source Control VIs.
These VIs are frequently used to automate scheduled tasks such as automatically getting the latest version of all VIs from Source Control at a certain time in order to create a daily build at a scheduled time.
For instance, the following VI gets the latest versions of all VIs in a project and programmatically builds all the build specifications in the project.
Both the VI Revision History feature built into LabVIEW and Source Code Control software keep track of changes made to VIs using revision or version numbers. However, the revision numbers stored by these two methods are not synchronized or shared with each other. This means that a particular VI could be in its 40th revision in VI Revision History and 45th revision in your Source Code Control provider.
Most development teams keep track of revisions made to VIs using one or the other method. Typically, if a Source Code Control provider is used, development teams use the revision history provided by the Source Code Control provider because of the addition features it provides.
LabVIEW gives you the ability to compare and show the difference between two VIs or two versions of the same VI side by side in a graphical format using two built-in methods: the VI Comparison Tool and LVCompare.exe. Following guidance in Comparing Two VIs in LabVIEW for information on how to use these tools and their software requirements.
In a large application development environment, it is common to have multiple developers making changes to the same VI simultaneously. When the changes are complete, these changes need to be merged together to integrate the development done by each of the developers to the master copy. These changes can either be merged manually, which is a tedious and error prone practice, or can be automated using the Graphical Merge feature in LabVIEW.
Graphical Merge allows developers to merge multiple changes made to a VI. This feature is available both within the LabVIEW Development Environment and as a command line utility that can be called from Source Code Control providers.
Most source code control providers have built-in merging capabilities for text based files. However, if you attempt to merge LabVIEW VIs using text-based utilities, they will attempt to combine the binary data stored in the file. Source code control providers can be configured to call external applications upon the request of a merger between files of a certain file extension. In the case of LabVIEW VIs, the graphical merge functionality can be called externally and passed the appropriate parameters in order to perform the merger.
Calling graphical merge from an external application require the ability to pass parameters to the command line. In windows, the executable to be run is available at the following location:
<Program Files>\National Instruments\Shared\LabVIEW Merge\LVMerge.exe.
There are four required parameters and one optional parameter, which must follow the call to the executable:
For example, LVMerge can be called from the command line as shown:
This will merge Base.vi with changes made in Theirs.vi and Yours.vi and will save the resultant VI to Output.vi.
How this interaction is configured depends upon the source code control provider being used. In Perforce, this functionality can be configured from the Settings»Options menu. Select Merge in the categories and override the default for any file with a *.vi extension as shown.
Graphical Merge from LabVIEW Development Environment
The Maintenance stage of the Software Engineering Lifecycle often requires developers to keep track of not only source code versions, but also the versions of distributions built using LabVIEW. LabVIEW provides developers the ability to include version numbers with distributions built with LabVIEW. This ability is available for Applications (EXEs), Shared Libraries (DLLs), .NET Interop Assemblies and installers. You can set the version number of a distribution on the Version Information category of the Build Specifications Properties dialog.
This feature allows you to keep track of which versions of LabVIEW distributions are present on a system. To view the version of a distribution built in LabVIEW:
In addition, LabVIEW 2009 and later also provides more granular information regarding what versions of VIs were part of a built distribution. For instance, and application (exe) might be version 22.214.171.124 in LabVIEW, but its source VIs could be in very different revision numbers. This information can be exposed in log file that can be generated as part of a build.
To enable this build log, check the Generate build log file checkbox on the Advanced category of the Build Specification Properties dialog. The build log contains details on the build including the project details, the distribution version as well as the source code VIs used in the build.
A sample log for the scenario described above looks as follows, showing that the version of the distribution was 126.96.36.199, and the source VIs were in their 14th and 2nd revisions:
LabVIEW provides multiple mechanisms to track and manage revisions made to LabVIEW code, both at the source code level as well as at the distribution level through VI Revision History, distribution versions, integration with various Source Code Control providers and built-in tools for Comparing and Merging VIs.
Software Engineering with LabVIEW details the steps involved in the LabVIEW software engineering life-cycle.