Showing results for 
Search instead for 
Did you mean: 

Labview Source Control for Package Manager

Go to solution


I use Gitbucket and Sourcetree for source control. I have a cloned online folder on my desktop where I save all my files. When creating a new program I always make sure to include it in this folder so I can keep track of changes. Now, when I use third party LabVIEW drivers that I downloaded with LV Package Manager I am no longer certain how to integrate these into source control. The drivers automatically download onto my desktop. This means they are not included in my source control, so if I were to pull a code from source tree on a different computer the drivers would not be included. If I move the drivers out of their original download location and put them into the online folder this solves the problem, but they no longer show up on the functions pallet. This was the best solution I could think of, any suggestions? I am self taught in programming so my knowledge on correct protocol is sparse 😞

0 Kudos
Message 1 of 3
Accepted by topic author RyanLehman

We generally have a folder in our root SCC folder called "Third Party Code". I include a copy of anything we have used and place it there. If they are packages you downloaded via VIPM then you can create a list of the required packages and check that in. You can also get copies of the packages themselves and check those in. Include a README file describing what packages and drivers need to be installed.

Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 2 of 3

In my LabVIEW directory I have a folder for projects (each project gets a separate folder inside of that), a folder for Re-Use code, and a folder for Instrument Drivers. When I want to use an instrument driver (or re-use library) in my project, I copy it to that project. I have a little program to do this, but you can just as well do it manually. Each instrument driver and re-use library has a text file with the "version" of it, so as time goes on I know how up to date each project is.


The pros of doing it this way are:

- Someone can checkout the project and they will have all the dependencies right there, in the version required for that project.

- Making a breaking change to a dependency will not propagate into older projects which might not need the change.


The cons of doing it this way are:

- Fixing a bug in a dependency will not automatically propagate to all projects.

- Have many copies of instrument drivers / re-use code, but usually only amounts to a couple extra MB per project.

Message 3 of 3