Tortoise-SVN, tagging [only] top-level VI dependencies

[iwire]

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!

[asbo]

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".

[iwire]

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.

[asbo]

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?

[PaulL]

We are pondering exactly the same question. We have a Common directory that has code used in various applications.

I did quite a bit of searching on-line and decided the most complete way to handle this in Subversion is with Externals. Essentially, we can add Subversion properties to the directory for each application, where each property is the (absolute) path to an external directory. Subversion puts a copy of the external directory as a subdirectory of the application directory. (Yes, this means the applications need to relink to the files in the subdirectory.) (The new copy still links to the original repository directory.) When we tag the application, we can put a revision number in the externals property so we get the specific version back the next time. (If there is no revision number, Subversion just retrieves the latest version, which is not the idea when we are creating tags.)

There are at least two caveats:

1) Subversion doesn't put the revision number in for you. This is a manual--and error-prone step.

2) If you ever restructure your directories, you will need to redo all the externals properties (I think).

We have concluded that this will accomplish the goal (I tested it with a sample project), and it isn't too difficult to do. It is error-prone, however, so we are discussing whether or not to handle things this way....

[Yair]

You can see some more about using the Externals keyword here - http://thinkinging.com/2008/10/21/set-the-revision-of-your-svnexternals-or-else/

I would agree that using VIPM is a lot simpler.

[iwire]

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...

[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.

[PaulL]

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

You are correct--Subversion does not know anything about LabVIEW dependencies so the tagging process by itself won't sort this out for you. (I expect it is possible but nontrivial to do this with scripting--I haven't tried.)

For our way of working this is not generally a problem. Since all our VIs or controls are in collections (always in a folder--almost always in a class and maybe a project library) I just need to pick the directories to include. (In your example, I wouldn't choose the "utility" directory but the relevant subfolders.)

...

OK, strictly speaking it can make a difference in that I may later change code (a VI, a class, a library) that is part of the tag but that I don't use in my application, so that I might think I need to do an update when I don't strictly need to do so. I guess the question is how does it affect the use case? For us, not much, but maybe there is a situation where this could be significant.

...

I do think it would be cool if there were a tool that traversed the project and automatically included all the items in the project and the dependencies for tagging. It would also let me work with one version of common items in one application and another version of those same common items in another application simultaneously (which the tagging and externals combination does), and make it easy to branch from the retrieved code.

Hmmm.....

[asbo]

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?

That's correct, our VIPM packages install to LabVIEW's user.lib folder (though the package software supports just about any destination you can dream up) and when we write our applications we just drop those VIs from the palette. We maintain a separate repository for the "source" versions of these VIs where they can be developed and repackaged into a .VIP file. Just like VIs that ship with LabVIEW, it's considered a faux pas to edit any of these reuse VIs that were installed via package. It does take a little bit of setup, but when you've got it streamlined it's a brilliant system.

We keep a .VIPC (VI Package Configuration) file in the project's folder which is more or less a list enumerating which packages the project uses and which version of each particular package is needed. Coupled with a network drive that houses all of our released packages, it's extremely straightforward to install all the necessary reuse for a project on any machine.