Labview Revision Control

[Joe Ross]

Our team has decided to look very seriously at using labview next year. One thing that worries me is revision control. We started using CVS a few years ago to make it much easier for multiple people to work on the code. My favorite feature was the merge capability so that multiple people can work on the same file (and even the same line of code), since in the fast paced world of FIRST we don't always have our files as self contained as I would like.

I found the following document about revision control in labview: http://zone.ni.com/devzone/cda/tut/p/id/4633

We did use labview for the dashboard, and I stored the VIs in CVS, which worked ok. However, we only had one person working on it, so we only needed to store the revisions, no need for merging. Now that we will have everyone, merging would be nice, but the above document says that it is not supported. It does show graphical differencing, which would work better then nothing.

The only problem is that the document implies that you have to have a supported version control solution to take advantage of the graphical differencing. Most of the supported software costs thousands of dollars. The supported CVS client costs $27 per license, which adds up. Are there any cheaper ways to get graphical differencing?

[Greg McKaskle]

Originally Posted by Joe Ross

The only problem is that the document implies that you have to have a supported version control solution to take advantage of the graphical differencing. Most of the supported software costs thousands of dollars. The supported CVS client costs $27 per license, which adds up. Are there any cheaper ways to get graphical differencing?

The difference feature is part of LV, not part of the CVS or another repository tool. So, you can diff independent files, or revisions of the same file from within LV, and it is potentially independent of the CVS system.

Even with merge, you will want to use CVS a little differently. You will likely want to lock files to prevent multiple simultaneous edits. As you noted, it isn't quite as convenient to merge LV code graphs as it is to merge textual C files. The lock doesn't have to prevent simultaneous edits, but it means that both parties are aware of the upcoming merge, and aren't surprised by it.

Merge is in the works, by the way, and if you embrace subVIs and modular code, LV can scale to medium sized teams of SW engineers (10 or so). But the SCC tools and LV diff and merge features aren't mature enough to support large or huge teams easily, at least not yet.

Greg McKaskle

[lynca]

I've used revision control using SVN on Labview files, one way to avoid editing the same VI file at a time is to create sub-vi files. That way people can be editing sub-vi's without introducing conflicts between files. However you still can't edit the same file at the same time and hope for a successful merge (at least with the open source SVN available). I mainly use SmartSVN.