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.