Source Code Control-where to store source files?

[Colbrunn]

Let me begin by apologizing for my naivete. I am really interested in what VIPM has to offer, but I am pretty sure I am missing the philosophy of how to use it when it comes to source code control, expected path dependencies, code debugging and testing, and building packages. I could really use a quick primer on how to make this work. I have looked all over the help and videos on this website as well as lava. But I think I am missing something simple. This is a call out to all the super genius VIPMers.

 

Our Situation:

We have developed roughly 2500 reusable vi's and they are currently in user.lib and vi.lib. Everything is under SCC and when we create a new system we check out these files into the appropriate spot. As we make refinements and check things in, the other users can just update and have them in the right spot. Everything can be logically broken up into about 19 different packages. We also have developed an application in Program Files (~1000 vi's) we shall call ProgramX and there are calls many of these reusable vi's in user.lib and vi.lib. We are now distributing ProgramX and all of the 19 packages to customers and want to use VIPM to help keep track of all of it.

 

My Flawed Philosophy:

I was thinking that I could just build packages from the code on our systems and effectively zip it up for distribution to a customer to automagically place the files in the right spot. I would keep the .vipb file in the folder where the source code is (in the right place in vi.lib and under SCC). Then, if I wanted to make a new package I would build the latest and away we go. As you know, and I recently learned, VIPM won't build files under the LabVIEW 20XX directory. There goes my grand plan! It looks like I have to build the packages from the files when they are out from under this directory. I tried just copying and building, but it complained that I had copies named the same thing under the LabVIEW folder. I then removed the files from the vi.lib folder, but then it complained that the dependencies were missing. So, it looks like I have to actually use some other 'project folder' for development, and then build from there and install into the vi.lib folder so that ProgramX (from Program Files remember) refers to the right files in the vi.lib folder. You might say, duh! that is how it is supposed to work. I get that. However, that makes development and refinement of all these different code groups a pain. Now, if my cube-mate who is jointly working on development with me wants to get the latest, they need to check out or update the project folder; build a new package; install the package before they can get the change that they used to get with a simple SCC update command. Also, if my aforementioned cube-mate has to make a change to that code, they need to copy that change back into the project folder to be able to put it back under SCC. The alternative is that the ProgramX refers to the project folder for development, but then before I build that into a package I need to delete that folder and force labview to find and replace all the references to the installed package in the vi.lib folder rather than the project folder for that given sub-package. This also seems like a pain.

 

My Plea:

Though I don't understand it, I am sure there is a good reason that VIPM can't build from folders under the LabVIEW directory. The two alternatives seem manual and prone to error. It is VERY possible that there are better ways to do this that I have not thought of. Can someone please give me the VIPM expected model for developing and maintaining version control, and proper expected call references for multiple packages of code. I am really hoping there is a simple solution. Any advice would be greatly appreciated.

[jkittle]

It looks like I am having the same issue with using vipm.

 

I’m developing code to distribute using vipm. I’ve written the initial code and have it in MyDocuments. I then created a vip that installs the code in the user.lib directory of LabVIEW. I am now debugging this code inside the user.lib. Any changes I make then have to be copied back to the original code in MyDocuments in order to create a revised vip. This is very tedious. I had tried to create a new vip from the modified code in user.lib, but vipm won’t allow this. Error message:

 

The following source VIs are located beneath the LabVIEW application folder. You cannot locate your source file under LabVIEW.

 

I’m hoping that someone will have a better way of going about this.

[todd]

Reuse package source for my (very small) group goes in c:\reuse\<package name>\

Each package folder has its own scc repository and associated bug/feature tracking and wiki.

Post-build package options are set to lock VIs, CTLs, lvlibs, lvclass, ... That way, when packaged code gets used in a project and someone tries to debug into it, they quickly realize they're in a package, not in their source anymore.

 

If the package is complex enough that you need to edit it often, leave it unlocked during development. Change it in c:\reuse\..., build, install, debug from the project that calls the packaged code, repeat until it's robust. If the package source changes every day, it's not really a package, yet.

[Michael Aivaliotis]

I suggest you watch this video:

http://support.jki.net/entries/22611406-Getting-Started-with-VIPM

There a good section in there regarding the package development process.

 

You should not be editing VIs beneath LabVIEW, regardless of their origin. Packaged or not. You should be modifying your project source which should also be source code controlled. You can test and debug your source before it's built. There may be some benefit to testing the built package after it's installed. But changes to the source should be made in source. Let's take, for example, the scenario of building an executable. You test and validate your development source. You then build an executable. Then you test your executable. If you find issues in your executable, you then edit the source, fix the issue, commit your changes to SCC, and rebuild. You apply the same principles when building packages.

 

As Todd mentions, you could add some editing protection. There's a feature to lock VIs during build as well.