The LabVIEW Professional Development System is a Microsoft SCC enabled environment, which allows integration with a majority of source code control tools through a standard API.
Of the many third-party source code control providers used with LabVIEW, Perforce and Subversion are popular choices.
Perforce, which supports the Microsoft API, can also be integrated from within LabVIEW using a custom command-line provider that is included with the professional version of LabVIEW. Integrating Perforce from within LabVIEW offers several advantages over the standard API as it enables the use of more advanced functionality.
Subversion, a popular open-source solution, does not support the standard Microsoft SCC API. However, it can be setup through the Tortoise client to call into the LabVIEW environment in order to invoke graphical diff and merge utilities, which requires some basic configuration. Additionally, a variety of third-party products are also available to help with this integration, including:
Fundamentally, there are two approaches for the integration of LabVIEW and a source code control tool: either LabVIEW can be used to call the SCC functionality from within the environment, or the SCC tool can call into LabVIEW for the sake of operations like Diff and Merge.
Configuring LabVIEW to Call the Microsoft SCC API
Once your source control provider of choice has been installed you can configure LabVIEW to allow developers to use source code control functionality from within the development environment, if it supports the Microsoft API. The goal of providing this integration is that developers can perform common tasks such as checking in and out of files and view the current status of files without launching a separate client or leaving the LabVIEW development environment.
Some source code control providers may offer proprietary or advanced functionality that developers still need to go into the client to use; however, a majority of the time, they should be able to perform these operations from within LabVIEW.
Integration can be configured through the Tools > Source Control menu. This functionality is only available in the LabVIEW Professional Development System. Any source control provider installed on your computer and supported by LabVIEW will automatically populate the options dialog.
Figure 2 illustrates where users can enable source code control integration from within LabVIEW.
Source code control can be used to manage any resource in your Project Explorer that has a corresponding file on the hard-drive. This includes VIs, documentation, images and the Project file. Requirements documents are frequently stored in source code control so that developers can track changes to documentation and view the history of revisions. This can be especially important for certified development practices, which often require developers to demonstrate that changes to requirements were covered by code. Learn more about requirements management best practices.
If source code control is configured in an existing LabVIEW Project, the addition of any previously saved VI to the Project will prompt the user to add the new file to source code control. This prompt will only be displayed on existing files. New VIs do not have a corresponding file on disk until they are saved; therefore, they cannot be added to source code control. Adding files to a Project during development introduces new links and results in modifications to the Project file, which must be carefully managed and is discussed in greater detail in the next section.
Managing the Project File in Source Code Control
It is recommended that an application's Project file, or *.lvproj file, be stored in the source code control repository. This file contains links to physical resources in the Project Explorer using relative paths to the location of files, the settings specific to a particular project, and virtual items such as the build specifications. It is important that all developers have the most recent version of the *.lvproj file in order to ensure they have all the latest dependencies and resources.
Adding or renaming files in a Project will alter the contents of the *.lvproj file, which requires checking it out and submitting a new revision to the SCC provider. Since these changes affect all developers using the *.lvproj file, it is inadvisable to make any modifications during development. If changes must be made, they should only be made by one user at a time, and all other developers should get the latest revision of this file as soon as changes are complete. However, there are alternatives when this is not possible.
Ideally, the framework for the application is determined before development, and placeholders already exist for all future code and functionality. However, changes are sometimes required that force modifications to the framework and therefore to the contents of the *.lvproj file. These modifications can potentially affect linkages throughout the application and should not be taken lightly. The recommended practice is to make these modifications offline and outside of development - all files should be checked in to the depot and locked to prevent checking out. It is also important to ensure that new code is covered by requirements documents and that they describe why the files are being added.
Alternatively, many developers may opt to have their own copy of the .lvproj file. This is generally only recommended when the application can be compartmentalized into separate, self-contained sections. Project Libraries (.lvlib) may also be used to organize an application into discrete components.