DQMH Source Control folder locations - Best Practices

[carlos_camargo]

Hi all!

We're working on a project writing code in LabVIEW and using GIT for Source Control.  We're creating class wrappers for drivers which can be anything provided by a COTS manufacturer to SCPI command drivers.  We're also creating DQMH modules to interface with the class-based drivers.  Higher-level code will also be written as DQMH modules.

"Parentage" will look like this:

  DQMH_Power_Supply   <---  This will be kept in Working Copy

      Class-Based_Power_Supply_Wrapper   <----  What is the best place to put this?

           Agilent_Power_Supply   <---- This and everything below it will be copied from Working Copy to instr.lib

           BK-Precision_Power_Supply

           Simulated_Power_Supply

Our plan is to keep all of our DQMH modules in the working copy area.

The drivers will be copied over from the repo into the instr.lib folder.  This is in lieu of running every driver install on each development machine.  So the Class-based driver wrappers will be written to know the drivers can be found in instr.lib.

The question is, where should the class-based code be located? 

The options are:

   1. Keep it in the Working Copy location

             Pros: It is always going to be code that we create ourselves so belongs in the working area

                      Code is held in one area and the possibility of cross-linking is very low

                      Work flow is simpler, there's less possibility of confusion as to where to make changes.

             Cons: Code won't show up in the Palette

   2. Copy it from working copy to user.lib or instr.lib

             Pros: Functions will be available in the Icon Palette

             Cons: Code is in two different locations

                        Updates to repo code require copying of updates to new location - possibly through an installer

                        Changes to the code will be made in user.lib (or instr.lib) then copied over to Working Copy and pushed on to remote

                        Functions we need from DQMH modules are harder to find in the palette than LabVIEW project window.

Thanks in advance!

[Gregory]

Hi Carlos,

As long as you are consistent from project to project, I think it is just a matter of preference.

I have a copy of my re-use code and instrument drivers in their own repo. Then, when I need them for a project I copy them into the project folder as well (you can do this manually or with scripting). 

The main repo will have the latest version, which I save in a text file just as a note. When the version inside the project becomes out of date, sometimes I will have to propagate those changes to every project that used those drivers (if a bug was fixed), but other times I will leave the old copy (if I was just adding some new functionality).

[carlos_camargo]

Hi Gregory,

Thanks for your response.  Correct me if I'm wrong but, it sounds like you keep a reusable set of drivers in a separate repo and maintain those separately from your projects.  Then, at project inception, you'll copy them out of the repo (breaking the link to the instrument driver repo) and into maybe a driver folder in your working copy and use them in the new project repo with no link to the instrument driver repo.

Where do you keep vendor level drivers?  Do you move them to instr.lib or have them placed there by vendor-provided installers?  Or do they stay in your working copy folder?

Do you keep all of your driver-level class files and DQMH modules in your repo working copy?

Thanks,

 C

[Gregory]

Hi Carlos, yes I have repos exactly as you mentioned.

When you say "vendor level drivers", are you talking about LabVIEW drivers / VIs, or something else? If you're talking about LabVIEW VIs, like the ones downloaded from the "Instrument Driver Network", I leave those in my project folder. I try to avoid instr.lib since it is shared among all LabVIEW projects.

If I make a DQMH module that is generic enough to be used in multiple projects, I might store it in my "instrument driver" repo. But most modules are somewhat project specific, so they only live in my project repo.