Tortoise SVN and LabVIEW linkage

[mmersch]

I know that Tortoise subversion is not officially supported by NI but I also know that some of you are using it nevertheless to handle your source code control. We have started to use it about half a year ago and are in general happy to have it. The problem I actually have is that Labview is so picky about the linkage of the vis and I am trying to fix that with the Tortoise feature to "switch" a directory, i.e. make its content actually link to a different location. Let me explain:

We have organized our applications in projects of which we keep a development and release versions (trunk and tags in svn terminology). Apart from that structure we have an intermediate programming layer, i.e. code that is used by several of those applications, e.g. device drivers or a file structure handler. Those "tools" are usually developped/extended/bugfixed when working on one application or the other, while the other applications shall continue running with a stable version. In the end all applications shall benefit from the improved tool.

We have therefore two basically identically subdirectories "tools/trunk" and "tools/tags" which contain the development code and the stable code for the tools. It is no big problem for a single project to include tools from the trunk and the tags directory and you can see nicely in the "Files"-tab of the Labview project explorer which parts you are actually using. It is already tricky to exchange the trunk-version of a tool by its tags version once you have released the tool. Really bad is however that when I mix tools from the trunk and the tags directory in a labview project. Then it is possible that a tags VI calls a trunk-VI and gets linked to that path. This in turn causes linkage problems in other Labview-projects that are supposed to use only VIs from the tags directory. Can you still follow?

Anyhow, my fix is that I have introduced a third directory "tools/switch" which I switch with Tortoise to the tools/trunk or the tools/tags directory as a whole and all Vis and Labview-projects reference to that switch directory. In principle it would be possible to switch the subdirectories of tools/switch individually to the trunk and tags version but as Tortoise does not transparently indicate which folders are switched I easily loose track.

So what is your strategy to handle development and released versions of this intermediate code layer that shall be synchronized for several applications? How do achieve labview to link to a new location to include a new release version?

Your suggestions are very welcome.

Thanks,

Matthias

 

[F._Schubert · Accepted solution]

Have a look at jki's blog

thinkinginG

there is a post about using the 'externals' tag in SVN (search for that keyword), which might solve your problem.

Furthermore, there are some options in LV that it won't save primitive changes like a recompile. I don't remember where I found these settings.

Felix

[elset191]

http://www.jkisoft.com/tortoisesvn-tool/

I haven't tried it yet.  I plan to soon though.

[Jim_Kring]

Hi Matthias,

Sorry, if this reply seems like a products plug (which it is), but this is really how we solve this software engineering challenge at JKI...

At JKI, we create VI Packages (which are basically installers for LabVIEW instrument drivers and toolkits) of our reusable code (using the package building capabilities of VIPM Professional).  We keep a VI Package Configuration file (that includes a copy of the actual packages) in each of our project folders (and check it into source code control just as we do for all our project files).  We also use VIPM Enterprise to distribute new VI Packages over the network.

Also, as others have mentioned, we use the JKI TortoiseSVN Tool to make it easy to use TortoiseSVN directly from LabVIEW.

Please feel free to contact JKI if you have any specific questions about these products.

Thanks,

-Jim 

[mmersch]

Hi Felix,

thank you for the tip with externals. The full link is  http://thinkinging.com/2008/10/21/set-the-revision-of-your-svnexternals-or-else/http:/thinkinging.co.... It is even fairly well documented in the Tortoise Manual, I wonder how I could miss it.

Overall it sounds like a viable way to include libraries into several projects without the need to copy the code. In general I explicitly want my projects to adapt to new releases of libraries automatically without the need to actively think of every application that is using the library and needs an update. As suggested in the blog, I can include libraries with a certain revision number if necessary. Finally I can change those libraries between development version and release without labview having a linkage problem and it is still quite transparent to see, which librairys are included in which version.

I will try it next week.

[mmersch]

I have now tried the externals functionality to include external libraries into my projects:

• The principle is great. I have now standalone projects totally encapsuled and at the same time I have easy synchronization with the external repository.
• One needs to be careful when working on more than one project that use the same external VIs. It is easy to create conflicts when changing the same VI in both projects.
• My updating takes now extremely long. It takes a few minutes until the transfer of files starts, even if the directory is small. And that delay repeats for every external directory. Is this usual behaviour oris something wrong with my settings? (By the way, it also takes up to several minutes to delete unversioned files in a versioned directory on my computer; however this is not related to externals; has anybody help though?)

[dsavir]

Hi all,

I also tried using externals to use basic tools in another project, but it has led to some unexpected behaviour. On my computer everything works fine. When the other programmer checkout this (with the externals) the project completely freaked out. It showed the following errors:

1) Global.vi: Not executable (This is legacy code, it relies heavily on globals. We're rewriting the code now and believe me we will not be making this mistake again). How can a global be not executable? When opening the global it shows the OK with a red circle around. Pressing on that causes Labview to crash and exit.

2) used a different folder, tried again: It seemed to randomly take things from LV 8.5 (we have LV 8.2 and LV 8.5. The legacy code is in LV 8.2. We have not upgraded it due to the incredible headache involved). So it complained that in lvanlys.dll there is no Gamma85, bacuase it took the vi from 8.5 and the dll from 8.2. In addition, it also freaked out on the globals, switching around values. There were literally hundreds of errors.

I stress that when checking out in my computer it works fine.

Anyone have any ideas?

Thanks,

Danielle