iwire

I hope that didn't come across as cutting, I was just pointing out another way to look at it.

This is perhaps side-stepping the problem, but we use VIPM packages for all of our reuse code, which installs to vi.lib and doesn't get versioned with project code. Instead, we version a VIPC file which lists all the reuse code the project needs and what versions of the reuse package. This might be a useful workflow change for you to consider.

If you'd like to solve the problem in SVN exclusive, I'm afraid I don't use tagging in depth enough to be more helpful. Can you simply not select the utility folder when doing the tag, or are the utility VIs versioned per applicaion? Maybe a folder structure diagram could help clarify?

asbo,

No cuts, just embarrassed. Linking the main-VI to shared/reusables does make application (embarrassingly) vulnerable to modification. It bugs me and you pointed it out immediately!

I don't use the VIPM - not sure I understand it's application here. Is this controlling a VI-lib object which application SOURCE code refers to? Or, does the VI-lib object live on targets with deployed apps?

Re: SVN and tagging dependencies (VIs) automatically.

The tag will identify the app&version being released and shouldn't show-up on any objects(VIs) under Common folder - unless the VI is part of current released app.

This would seem to imply a "high" degree of integration between SVN and LabVIEW - maybe unrealistic.

Paul, Yair - Thanks.

I followed link re: "Externals" and read JK's coverage with great interest. If I understand correctly, tagging is applied to folders (via symbolic-link)(?)

Am still hoping to tag only VIs that are part of an application being released...

What if your utility VIs change? Every time you update reuse VIs, you run the risk of breaking code that calls it.

Seems to me like it would be a good audit of how your reuse VIs are being used as well, so long as your tags are along the lines of "applicationname-beta-n" instead of just "beta-b".

asbo -

Ouch! - Yes, this shared-area, open for edit, is a liability. Of course edits can be made with existing code in mind.

While I'd like to create/control application-specific instances (of generic VIs) with a release, I've no idea how this would be handled as far as (unique) VI naming/organization, or how I'd track every usage of a generic VI, in case it needs a bug-fix.

Again, any/all ideas are welcome.

Hi Steve,

In order to help troubleshoot these kinds of dependency-issues with dynamic calls, it can be useful to open the FP of all a VI's broken sub_VIs. I typically check for errors when loading the dynamic VI, and if the open throws an error, then call an "OpenBroken.vi" (passing it the VI path) which does a recursive traversal of the broken VI and its dependencies - opening only the broken dependencies. The deepest (broken) VI is the last opened - just click on the broken-arrow...

This method doesn't necessarily yield a better/good/more-helpful error message - in fact it's success rate is probably less than 50%. But when it does work, it saves so much debug time as to be well worth the investment!

I'm at home and didn't have access to this tool, so built&tested it again. (in other words, i think it will work...)

Luck/Cheers.

Util.VI.OpenBroken.vi

Greetings!,

A quick search didn't reveal any titles appearing to address this specific question...

My application's source-code is organized under two directories - a project-specific directory where all the sub-VIs and directories are part of the application, and a "utility" directory which contains a hierarchy of generic functions used by many projects.

When releasing an application revision, (i think) it's necessary to create a tag in order to obtain a snapshot of applicable VIs, however, if the tag is applied to the "generic" folder, it will be applied to many VIs, the majority of which are not applicable to the release.

I'm relatively new to SVN and wondering if SVN and LabVIEW can be integrated in a way that would allow a tag to be applied to [only] the dependencies of a top-level VI.

Any ideas, including alternative approaches, are welcomed!