LabVIEW Repository folder Structure

[SeanJ]

Hello Everybody,

We are pushing to clean up our code repository.  There's about 10 engineers using the code and the total source code repository has evolved over the course of several years. 

I've been tasked with putting some structure on this code.

I'm thinking of having a root with the following folders

-> Instruments     

-> Projects

-> Engineering Group

There will be multiple trees extending from the above.

I'm just wondering if anyone knows of a recommended structure to manage large repositories of labVIEW code?

Thanks,

Sean

[SteveChandler]

When you say repository I am assuming you mean source control repository. I hope you don't mean a filesystem structure.

You should start by identifying a "reuse library" of common functions. Maybe that is what is meant by "Engineering Group"? . Make that it's own project and put it in vi.lib. The easiest way is with VIPM. Your instruments should definately be a list of separate projects and placed in instr.lib.

[SeanJ]

Thanks Steve,

Thanks for the reply. Your assumption is correct.

Engineering Group will consist of personal folders for all engineering members using LabVIEW.  This is where they should do their rough work.

You're right a type of reuse library would good.  There'll be another folder called common.

Thanks for the VIPM suggestion but we don't want another third party software manager.  Subversion is our preferred choice.

"Your instruments should definately be a list of separate projects and placed in instr.lib." 

That's not our preferred method.  I want everything in a folder that can be checked out and work instantly for anyone.  If we start putting things in the instr.lib folder then if someone tries to run a project on a new PC it may start to look for instruments that are not present, then I have to go over and explain what to do, etc.

There are varying levels of expertise in the group with regard to LabVIEW and all users must be catered for.

So far there are four folders,

1. Instruments -> consisting of instrument VI's, llb's etc.

2. Projects -> mainly lvlib's in different folders corresponding to the project on which they are used.

3. Engineering Group -> Personal folders for rough work

4. Common -> Useful modular vi's for use across projects arrange into different folders.

I'm hoping to start on this next week so all recommendations welcome.

Sean

[SteveChandler]

Source control seems like such a hassle at first. It's one of those things that once you get into the swing of it you wonder how you ever managed without it.

VIPM is not version control - it is package management. Similar to RPMs (Redhat Package Manager) if you have seen that. Sometimes you have a project that depends on a specific version of an instrument driver. You update the instrument driver to meet the needs of another project and now the first project breaks. Maybe version a of the instrument driver needs a specific version of the reuse library. Managing the dependencies between individual projects is outside the scope of version control.

Here is a document describing a project layout for an open source LabVIEW toolkit. It is something you can install using VIPM.

I used to feel the same way as you about VIPM. However it is fully endorsed by National Instruments and is very easy to use. I know you said that your preferred method is not to use instr.lib but VIPM makes this very easy. Your reuse library can show up in the palettes. You would develop and test the reuse library and each instrument driver individually, build them into a package, then install them on the development machines. It is another one of those things that seems like a pain but turns out to be much easier down the road.

As far as the less experienced users go, if they are developing LabVIEW code they should not have any trouble with installing packages using VIPM. Someone else creates the package for them. Installing a package is as easy as double clicking on it.

There are a lot of issues when it comes to sharing code between developers. One is version control. The other issues are where VIPM comes in.

If you get about 50 minutes free where you will not be disturbed you should check out the code reuse webcast on the NI site.

It is free, easy to use and makes life easier. What more can you ask?