Multiple Developers - SCC and Enums

[jakestern]

I'm about to embark on a project that involves more than one developer. I've just read "A Software Engineering Approach to LabVIEW" by Jon Conway and Steve Watts, and I like what they've presented. They choose to use Enums defined as Strict Typdef custom controls to be the selector for case structures in their state machines. There are advantages to using either Enums or Strings for these case structures, but the one area I haven't seen discussed is what issues might arise when Source Code Control with either method.

With Strict Enums, during development, if one person adds a new element to the enum, then all subVIs need to be resaved. This involves checking out a potentially large number of VIs, often to do nothing other than resave. With Strings as the selector, this isn't an issue. Of course there are many other facets to the debate of Strings vs. Enums, but I'd like to know if this particular issue is really that big of an issue or not.

Have you developed with multiple developers using Source Code Control, and had problems with developers getting hung up because another person has a large number of files checked out due to something simple like a Strict change, or a (gasp) Globals.vi change? Also, with your SCC tool, how do you go about rapidly checking out all files that have changed? We are currently using CVS, which I have not yet learned to work with. I have LV PRO, but others only have FULL, so they do not have access to the built-in SCC interface.

[Grampa_of_Oliva_n_Eden]

QUOTE(jakestern @ Mar 16 2007, 01:34 PM)

...if one person adds a new element to the enum, then all subVIs need to be resaved. This involves checking out a potentially large number of VIs, often to do nothing other than resave....

This is not neccesarily the case.

If the sub-VI's case structure that uses the enum has a "default" case, then they do not require saving. Yes LV will wan to save them but you do not have to.

Now if the sub-VI is such that a default case is intolerable, then the sub-VI will require editing to add a case for the new enum values. In this case they will have to be checkd-out to do the changes.

Ben

[Omar Mussa]

There is a setting in LabVIEW that may be useful for you - I'm not positive but am fairly sure this will work for you. You'll also need to follow Ben's advice and keep a 'Default' case for each case structure VI that uses the enum otherwise the VI will break.

In the LabVIEW options menu select 'Environment' (LV 8.2 - I think its in a similar place for earlier versions but may not be exactly the same place)

Check 'Treat read-only VIs as locked' and then check 'Do not save automatic changes'. This can help reduce the number of *s you see a lot. Then, what you can do is use LV integrated source code control or just manually set all of your VIs to read only. At that point, whenever you change a VI, you will manually set that VI to 'read-write', save the change, then set the VI to 'read only' (if you are using LabVIEW's integrated scc, checking in/out a VI will change its read-write property automatically) . While its a small pain, all of the VIs you are not working with will not get a *.