Careers

Perforce is a Configuration Management tool for software development. Although it can be used to manage large multi-developer projects, the context of this article is to use it as a Source Control system with LabVIEW as a single developer. The Perforce Server also has a web based version. This article describes only the windows server and client installed on the same machine. Please refer to the perforce website at http://www.perforce.com/ for more information on other Perforce installation scenarios.


Licensing and Compatibility
The free version of Perforce provides a 2 user, 5 client workspace license. For additional users and/or workspaces, you must purchase Perforce. The alternatives to Perforce (for LabVIEW 8.2) are: Microsoft Visual SourceSafe, Rational ClearCase, PVCS (Serena) Version Manager, MKS Source Integrity, and CVS with the Push Ok Windows client software.

To get Perforce running on your Windows system, download and install both the "Perforce Server Windows Installer" and the "P4V Installer" (in that order). Install the server with the "Administrator - Typical" radio button checked.

P4V is essentially the client and developer user interface, and although the LabVIEW Project Explorer can virtualize this, it is often necessary to have Perforce open as well since LabVIEW doesn't have all of the features (i.e revert if unchanged). The server runs in the background, and as mentioned above, can be run web based with remote client connections.

Installation and Repository considerations

Although the download will guide you through an installation, Perforce (as of 04/06/07) does NOT provide a standard uninstaller via the Start->Control Panel->Add/Remove Programs panel. A subsequent download and reinstallation of the program will be necessary, and will provide an uninstall radio button option (reminiscent of an old LabVIEW Application Builder "feature" where the user had to re-run the installer to uninstall). My experiences with uninstalling various versions of Perforce is that it has been challenging, nicely put.

A "Repository" is where all checked-in source code modifications will reside. In Perforce parlance, the repository is referred to as the "Depot". In Microsoft Windows, the default location for this file is:

C:\Program Files\Perforce\depot.

*NOTE*: I do meticulous backups, some people do not. Even those who do may miss backing up the repository if they are only backing up their "My Documents" folder ( a common practice). Also, creating a shortcut to the depot in your "My Documents" folder (another common practice) will not achieve a good backup, and will only backup the shortcut file. If you are backup conscious, make SURE you add the entire installed Perorce path to your backups!{mospagebreak}

Configuring LabVIEW to use Perforce

  • Start Perforce, it will prompt you to open a connection
  • Type in your computer name for "Server"
  • Click the "New..." button next to workspace to create a new workspace
  • Click "No" when prompted to populate the workspace


Initial Workspace Creation

This step is required each time you want to create a new LabVIEW project under Source Control. LabVIEW needs to open a connection to a LabVIEW project file from the Perforce depot. SInce the depot doesn't contain your new project data yet, you'll need to do an initial checkin of your current code (including a LabVIEW .proj project file).

If you don't have any source code, and are starting a new project, create a new empty LabVIEW project file and save it where you'd like to keep it in your documents for checkin and checkout. I typically use "My Documents\LabVIEW\Customer\Project". Remember, you can have lots of projects and workspaces, so this should be a directory containing a single project or application somewhere in your My Documents, or whatever data directory you choose.

In Perforce switch to the "Workspace" view rather than the "Depot" view. Navigate to your LabVIEW source code files that you want to checkin to this workspace. Select all of the files with Shift+LeftClick, then Right click and choose "Mark for Add". Right click again and choose "Submit".

 


LabVIEW Source Control Configuration

You now have a Perforce workspace with revision #0 of each file checked in. The convention from here on out, is to add files to the LabVIEW project file. Each time you do this, LabVIEW will automatically prompt you to add the file to Source Code Control. Before you can do this, however, you still need to configure LabVIEW's Source Control. In the LabVIEW "Tools" menu, select Source Control -> Configure Source Control.

Select "Perforce SCM" for the Source Control Provider Name. Click the "Change" button next to Source Control Project to configure the project. Navigate to the LabVIEW .lvproj project file that you wish to bind to.

*NOTE* - you will need to change this for each unique customer or project that you are binding to. Since you can have multiple workspaces and multiple projects, you must make sure this is configured properly for the Perforce workspace that you are bound to.


If you want to use the "Diff" functionality, you will also need to configure the Advanced settings. Click the Advanced button, and select the "Diff" tab. Select "Other Application", and navigate to the LabVIEW executable. This will use LabVIEW to show the differences between different VI revisions, rather than a text based editor.


LabVIEW Project Explorer

The LabVIEW Project Explorer virtualizes some (but not all) of the functionality of Perforce. There are simple Checkin and Checkout icons on the toolbar that are also accessible via the right mouse click. Notice the checkbox next to each file in the project. Also notice that the project itself can be checked out at the very top of the tree.


So what are Versions, Source Control, and Configuration Management?

Let's say you had some LabVIEW code that runs on Pocket PC, but not on PalmOS. Most of the sub VIs run, but some key elements, typically user interface customizations, or in the case of a customer, product configuration tweaks cause defects at many levels in the system.

Many LabVIEW programmers will simply take a shortcut and start saving different names of VIs. Eventually, this becomes a mess. LabVIEW is pretty good about prompting for issues like finding same-named VIs in memory, or even finding things where they weren't expected. Nonetheless, typical users just click through prompts and eventually shoot themselves in the foot by saving things they wish they hadn't, or by not being able to find a specific piece of code.

Versioning, Source Control and Configuration Management aim to resolve these common types of development issues. In larger projects with multiple developers this can become quite complex. Add issues like forking and branching, and re-assigning developers to multiple projects and the scope widens.

The example for this article is to do a simple Revision for one developer. Although Perforce is capable of far more complex operations (like those mentioned above), this example wil use the "Label" feature of Perforce. No forking, No branching, No multiple developers. Simply labeling a collection of source code revisions to create a "Version" (i.e. Product_1.12.34)

  • Checkin Your Code
  1. In the LabVIEW Project Explorer, right click and checkin your checked-out code
  2. You can also chech it in directly in Perforce, but you will need to close and reopen your LabVIEW project
  • Label the revision(s) you wish to associate
  1. Usually, you'll want to label the latest revision of the files in the collection, but you can specify other revisions.
  2. In Perforce, select all of the checked in Files with a Shift+Left Mouse Click
  3. Right click all of the selected files and choose "Label"
  4. A good Label would be "Customer_Product_MajorVersion.Minor.Micro" (i.e. Tradewerx_Clairvoyance_2.0.15)

You now have the ability to get the revision (In Perforce, not LabVIEW) of all of the files associated with a particular Version (or "Label" in Perforce parlance). Simply right click a file or group of files, and get the revision based on "Label" rather than revision. You shoud probably exit LabVIEW when doing this operation, and you should make sure all code is checked in prior to checking out older revisions.

John Giannangeli is a Founder
and Principal Engineer at Giawerx