Merging/Comparing LabVIEW VIs

[Terry Sherman]

We know that the professional edition of LabVIEW has diff and merge capabilities, it seems that those capabilities are not present in the FRC edition of LabVIEW. What techniques for revision control, code management, etc are teams doing?

For example, we break up our design into modules and each module has an owner. This works great for the most part but when we need to modify shared code such as telop.vi or robot globals, etc, it gets harder to keep the changes straight. Using tools such as SVN have lost much of their value since we cannot diff or merge.

Thoughts? Suggestions?

[Greg McKaskle]

I don't have any magic wand or anything, but you may get some improvements by using the source control system with locking to avoid simultaneous edits, and to alert you of who currently has the file checked out. That and perhaps add some additional global files and make some of the teleop code be placed into further modular subVIs. That way you only need to check out the high level VIs like teleop in order to pass extra data between components.

Greg McKaskle

[josxdr]

If you can keep your VI size small enough, then the "eyeball diff" method may work. As long as you don't need to scroll around, if you can size the windows the same size and look at them side-by-side, maybe this is good enough to see the changes??? Does anyone have experience with this? I must agree with the first poster, not having access to graphical diff is a major drawback to using LabVIEW. Maybe NI can provide a special crippled version for FRC?

[josxdr]

Here is a comment from the NI forums regarding source code control for LabVIEW:

When I started mentoring a few years ago, the team did source control by periodicly copying and renaming the entire directory. That worked for backup, but misses the major advantages of source control (history tracking and simultaneous work). We set up CVS and now everyone is comfortable with source control, which I think will greatly benefit them in their careers (I meet many people at work who only use source control because they have to, and are missing the great benefits).

This year, we still used CVS with LabVIEW, but it felt like we were back in the old days of only creating backups. Without graphical compares, it was very hard to reconstruct the history. Without merging, we couldn't work on the same file at once. We tried to mitigate that by making small files, but that didn't always work out. It also seemed like many times, changing one file affected many others, and I never did figure that out completely. In speaking with my manager at work, he also complained that it was very hard to use source control with LabVIEW. If we can teach everyone now how to effectively use source control with LabVIEW, it may help the adoption of LabVIEW in industry, as some of the misconceptions get broken down.

Is this the experience of other teams? If source control is really not workable, I think my team will have no choice but to use text programming, no matter how wonderful LabVIEW is.

[TDohse]

Greg's advice is probably the best for the current software given to FRC teams.

Including diff & merge capabilities in the FRC version of LabVIEW for next season has been discussed at NI.

[Joe Ross]

Originally Posted by TDohse

Including diff & merge capabilities in the FRC version of LabVIEW for next season has been discussed at NI.

I'm strongly in the camp of teaching configuration management, and would love it if NI would include that part of the professional version.

[Joe Ross]

It looks like we may get at least some of those capabilities next year: http://decibel.ni.com/content/message/7319#7319. See BLAQmx's reply today.

[Joe Ross]

Here's some more details that NI just posted: http://decibel.ni.com/content/docs/DOC-6494