How to use LabVIEW in a multiple coder environment?

[ojohnsen]

The subject basically says it all.  This thought hit me the other day, now that we will be two persons (and eventually perhaps more) coding on a source code written only by me so far.  In my job, we commit and update source code to a SVN repository by using TortoiseSVN.  This works very well with C/C++, since the source code files are in plain text and will be merged by TortoiseSVN.  But since VI files are binary, I gather that this will not be possible.  I tried comparing two different revisions of my own commited code, and this didn't work.  How is this particular problem solved in other multideveloper environments?

[Norbert_B]

Using Source Code Control is the very basic idea and should be mandatory for every developer team.

That being said, you already did some investigations in this field. One tool i want to point out for you is the VI Merge Tool. This will enable you to do at least some "semi-automated" merging of your work.

Another thing you have to keep your focus on: Modularization. If you split your task into well-designed modules, each developer can implement different modules. When it comes to integration, of course all modules have to be used in the same sources. So there comes the time where you either break the task down to a singel developer task or you can use the quoted merge tool.....

hope this helps,

Norbert

[Ben]

Source code control merging and all of that stuff is secondary to the design itself. I have had a half-dozen developers working on the same project but different "sand boxes" and yes we managed to get 6 person months worth of work done in a month.

Integration of tested components is when things get touchy but if done in a orderly manner, no suprises there either.

Rules that have helped us;

1) Use  Tree.VI  (or Root.vi , Catalog.vi) to hold all of the top level VIs. This will ensure we find out about possible integration issues when they happen.

2) Never save broken code to SCC. It is all too easy to start ignoring a broken tree.

3) Communicate with your team! let them know where you are going next.

4) Assume your team mebers will mis-use your code and build in error checking to let them know what they did wrong.

5) Never save a VI unless you can explain why you are saving it.

Backup-up often.

Ben

[Broken_Arrow]

What Ben said. But I'll add one more. Use Projects. This may seem obvious (since version 😎 but I still see multiple-VI programs without a Project.

[F._Schubert]

One thing that helps is that you have plenty of files (vi's), so merginging is done at the file level instead of the code (text).

Felix

[ojohnsen]

Thanks for the great replies!  Considering what you said, I think we'll have to modify some of the main code.  Otherwise, we'll be using the LV Merge option at every turn.

---

@Ben wrote:

1) Use  Tree.VI  (or Root.vi , Catalog.vi) to hold all of the top level VIs. This will ensure we find out about possible integration issues when they happen.

 

5) Never save a VI unless you can explain why you are saving it.

---

1)  I'm not sure I understood that one.  Can you explain a bit more?

5)  On what level would you explain this?  Just by having a changelog file committed along with the source code, or by writing VI decriptions or showering the code with labels here and there?

BR,

Øystein.

[Ben]

This thread from over tens years ago by Greg McKaskle talks about a "FakeRoot.vi". These VIs are just containers for all top level and and are never intended to run (I tell myself that when I accidently hit ctrl-r with the Tree. selected). They guard against changes affecting dynamic VI without you knowing. They used to fullfil the gap filled by the Proj file bu they are still useful.

Re: saving VI's

There are many reasons a VI can want to be saved. Check out the dialog box to see why. Sometimes the changes are expected but if you sudenly find a path has changed etc, it is time to stop and investigate.

Ben

[LV_Pro]

I too misunderstood what you were saying in #5, reading it more that if you are saving a vi you should be able to explain in the VI Properties:Revision History. You are just saying, don't hit save everytime you have a "dirty dot", know what has changed first. Of course, when it comes to projects I find that it frequently opens from a previous save indicating that it needs to be saved, but it can't tell me why.

[ojohnsen]

LV Pro: Good point.

Unfortunately, though, it seems that LVMerge is out the window, since it seems to not be a part of the base LabVIEW package.  I see that LabVIEW support a number of both free and proprietary source code control systems, but it seems that all of them will be based on using LVMerge when it comes to merging VI's (http://zone.ni.com/devzone/cda/tut/p/id/9924#toc4).  Is there an alternative to LVMerge for merging VI's?

[tst]

If you're using LV 2010, it finally has a feature which allows separating the object code from the source code. This will allow the files to have actual changes only when you change them, as opposed to previous versions which always asked you to save recompile changes unless you made the VIs read-only. You can see more on this here (and I suggest you also look at the rest of the content in that group, as part of it is relevant for this topic too).

As for your last question, there's probably no other alternative to merging LV code. It's not the kind of thing anyone would want to write if there was an existing solution.