LabVIEW with SVN Extenerals

[Dealcs2]

I am using SVN and LabVIEW together. I have a LabVIEW project, A, that uses a library, Z. The library is configured in SVN as an external, which works great—everything functions as expected.

Next, I export Project A as a source distribution, placing Library Z in the “Always Excluded’ folder. I then create a tag of the source distribution output in SVN. Later, in Project B, I pull in Project A via an SVN external and Library Z as an SVN external.

At this point, all the dependencies from Project A are included in Project B. The main issue is that both Project A and Project B have VIs that reference Library Z in different locations. I don’t want to (nor does it make sense to) play the folder alignment game of keeping the library in the exact same location in both projects.

As a result, when I load Project B in SVN, I get a lot of Resolve Conflict prompts. The prompt typically shows that one VI could not be found at a certain path that doesn’t exist, while another VI is found at a different path.

Why can’t LabVIEW simply use the VI that’s included in the project? I add Library Z to the project so it knows which files I want to use. This whole process has become a burden, so any thoughts or suggestions would be greatly appreciated.

Thanks!

[GerdW]

Hi Dealcs,

---

@Dealcs2 wrote:

Why can’t LabVIEW simply use the VI that’s included in the project? I add Library Z to the project so it knows which files I want to use. 

---

Because subVIs are referenced with their full path. When they are within the project, but in a different location, then you will get a "VI has been moved" warning and you need to re-save the caller VIs atleast once.

---

@Dealcs2 wrote:
This whole process has become a burden, so any thoughts or suggestions would be greatly appreciated.

---

You have several options to place re-use code in LaBVIEW:

• there's the user.lib to place commonly used code
• VIPM places libraries in the vi.lib by default
• we use a separate "Library" repository in SVN, which is placed in a folder next to the projects folder on disk. All projects can access/use files from this "Library" folder…
• …

[Dealcs2]

Thanks for the quicks response! Is this the folder structure that you are suggesting? Does this make all of the libraries relative to the LabVIEW project file?

Libraries

- Library Z

Project A

project_a.lvproj

Libraries

- Library Z

Project B

project_b.lvproj

[BertMcMahan]

I'd recommend a different approach.

If you haven't tried out VIPM, give it a shot. It makes reuse libraries a million times easier.

When you develop Library Z, make a VIP using VIPM. Install that VIP to your vi.lib folder. When you use library Z, make sure you use the copy in vi.lib.

Now when project A uses it, it uses the vi.lib copy. If Project A is also a reuse library, also make a VIP for it and install it to vi.lib.

Now, everything uses the same copies of all libraries.

VIPM is an excellent tool, and it's REALLY easy to make installers for your libraries. Give it a shot- I guarantee the first time you use it it'll save you more time than doing the Resolve Conflicts dance.

[rolfk]

Files that you directly include in the project overview are referenced relative to the project directory. If your Vis include them without them being part of the project, other than in the Dependencies folder which is autopopulated when loading the project for any items referenced by any included VI but not explicitly part of the project, the path stored in the VI is relative to the actual VI using them.

There are specific exceptions to above relative reference:

- If the referenced VIs are located in one of the well known locations such as user.lib, instr.lib, or vi.lib inside the LabVIEW directory, the project (or VI) stores a so called symbolic path reference. This is stored with a pseudo top level location <user.lib> or similar as first element of the path.

- If the referenced path is on a different volume than the referencing entity, LabVIEW stores the absolute path as reference. This also applies to UNC network paths. 

[Dealcs2]

Hey Bret,

Thanks for your response! I tried VIPM a few years ago and had mixed feelings about it. It seemed to take a long time to open and get started? Also, does it publish your code and make it available to everyone? Due to the nature of our business, we can't share our code. I noticed there is a Pro version that allows you to keep your code private, is that correct?

[BertMcMahan]

It takes a bit to open up if there are a lot of external libraries it needs to download. Once those are cached it's fine, so on a new computer or one that hasn't been used in a while, it might take a minute to parse through all of the various repositories it's monitoring.

And no- it doesn't publish anything at all, actually. It lets you GET code from VIPM.io (and maybe one or two more sources) but AFAIK you can't publish using VIPM, you have to go to those sites and manually publish stuff.

You use it to both install packages and create them. When you create a package, it just makes a .vip file on your computer- that's it. No publishing at all. You can then send that VIP file to your colleague who double clicks on it and it'll install that same package to their computer (they will need VIPM to install VIP's, of course). Super easy!

Also, you can also make vipc's, which are collections of vip's, which lets you collate all required packages for a given project.

All of that is free. The pro version does add more stuff, but I doubt you need that just to get started with it. For example, I think the free version lets you make VIPC's that list all required packages, but you still need access TO the packages to install the VIPC. Pro lets you bundle all required packages into an offline-capable installer.

Also also, have a look around vipm.io. It has a TON of REALLY useful packages in there. Basically anything from OpenG, MGI, JKI, or even NI themselves are going to be very well thought out, very well tested, etc. and are generally broadly useful. There are a lot of very specific things in there, too.