LabVIEW Resue: is using SCC enough?

[Daklu]

I thought that everyone uses LabVIEW because it's fun

Shhh! Don't let the managers hear.

Saving your money to spend elsewhere is a great idea (BTW, VIPM Enterprise is going to be released very soon )

I actually thought about that and almost made the same comment. I've mentioned before that I really like JKI's products, but earlier this week I learned we'll be using our scc platform as a distribution mechanism for our reusable code. It's a little more direct in that it eliminates the package building process (not that it's terribly difficult) and VIPM doesn't need to be installed everywhere, but we lose the flexibility of easily installing files (dll's, .net assemblies, etc.) to different locations. Any other differences I should note?

Also, the NI toolkit doesn't require you to write code (except for setup and teardown, which, essentially, almost every test needs).

Hmm... I guess I'll have to take a closer look at the NI kit.

[Ton Plomp]

.... Any other differences I should note?

How are you dealing with multiple LabVIEW versions?

Ton

[crelf]

Any other differences I should note?

Yeah - using SCC doesn't *manage* your reuse library (and, hence, the reuse in the projects that you work on) - it only distributes it. We used to use SCC for our reuse, but it's next to useless when looking at reuse on a project-by-projcet basis.

[Daklu]

How are you dealing with multiple LabVIEW versions?

That's a good question--one I had not considered at all. My initial response is to have a branch for 8.6 and a branch for 2009 but I don't think that's a good idea. Keeping multiple code lines synched up will be a real pain. I suppose we could do all our reuse code development in the earliest version we support and let LV recompile it on test stations that use more recent versions. Not that I like that idea either... I already get frustrated in LV8.6 when Ctl-Spc, Ctl-T doesn't reposition my labels. Any suggestions?

We used to use SCC for our reuse, but it's next to useless when looking at reuse on a project-by-projcet basis.

I don't understand. Our target computers will be hooked up to our scc system anyway, so isn't it simply a matter of mapping the reuse library's scc directory to the proper location on the target computer and downloading the tagged revision we want?

[crelf]

I don't understand. Our target computers will be hooked up to our scc system anyway, so isn't it simply a matter of mapping the reuse library's scc directory to the proper location on the target computer and downloading the tagged revision we want?

Not really - what you're proposing (as far as I can tell) is a monolithic reuse library - read here and here on why that's a bad idea. Having a monolithic reuse library is fine to start with, but then becomes unmanagable over time (trust me - it's happened to companies that I've previously worked at - twice! )

[Daklu]

Actually, I'm in the early stages of redesigning the current monolithic reuse library into something that is much more modular. I fully agree monolithic libraries are generally not a good idea, having seen how well (*cough cough*) they work first hand.

However, unless I'm missing something the distribution mechanism (scc or VIPM) is completely independent of the modularity of the code being distributed. Assuming the reuse library is appropriately modular there's nothing stopping us from mapping only specific library modules (or specific versions of modules) to the target computer, right?

[crelf]

However, unless I'm missing something the distribution mechanism (scc or VIPM) is completely independent of the modularity of the code being distributed. Assuming the reuse library is appropriately modular there's nothing stopping us from mapping only specific library modules (or specific versions of modules) to the target computer, right?

Sure - but then how do you manage the reuse library? VIPM allows deprecation (it's not an important feature - until you need it ), as well as dependancies (a really really important feature) that track between the versions of the library components, and you can create reuse snapshots (useful not only when baselining a project, but also when switching between projects that depend on different versions of different components: don't laugh at me - it happens! ) All that, *and* a tidy methodology of distributing your reuse components, *and* access to the OpenG packages too (if you use OpenG, your users already have a copy of VIPM installed, right?)

Besides, it's just so much more organised. We have a formal process in place that controls how and when items get into our reuse library (we don't want just anything in there, potentialy taking down our projects, plus we don't want duplication, plus we need a controlled method of getting updates out to users, etc, etc, etc). I'm sure Jim would butt in here and give you a billion more reasons on why SCC is so difficult to manage, but his missus Beth is currently in active labour to deliver the kingling - we're all thinking of you Jim and Beth!

[Black Pearl]

I shouldn't post late sunday night, but I can't resist. I have started to do some reuse vi's in the last half year. Deployment was a copy on the USB stick to my fellow programmers. I'm still in a process to learn the pitfalls on my own. This is mainly about writing them in a way, that I will never break my projects.

As I'm pretty sure that I won't get a VIPM budget, I also was looking on SCC to at least give my some ways. My idea (it's SVN) was to have a root hierachy of LV versions, below that the trunk/tags and have the user (me at the moment) check them in on the user.lib folder. I only use the trunk for now (it still is a private project for me).

My own impression is, that I save time against not using any of these (reuse, SCC), but I would be better of having a management tool for that (VIPM Pro). But for me currently the biggest barrier is to get the other developers use such tools (and they do a good job despite it).

So the biggest pitfall? I threw vi's out of the reusable, other projects did rely on. Very intentionally. And also decided to get some older concepts back in. Was worth the troubles, as I had used OpenG builder to have an llb copy where the originals where in. In fact the problems I did survive with an older concept of having a 'reuse' folder somewhere on my HD which maintains a copy of what is not in the user.lib and SCC.

But, problem unsolved: how to get my team working with it/benefit from it?

Felix

[Daklu]

Breaking this off into another thread threw me into a loop. I thought maybe I had hit a time warp and it was last Thursday again.

Sure - but then how do you manage the reuse library? VIPM allows deprecation (it's not an important feature - until you need it ), as well as dependancies (a really really important feature) that track between the versions of the library components, and you can create reuse snapshots (useful not only when baselining a project, but also when switching between projects that depend on different versions of different components: don't laugh at me - it happens! )

You could depreciate a module with a scc distribution system by simply getting a previous version instead of the latest version. Once you figure out which library components a project needs you could apply an scc label to that set of components to make it easy to switch between projects. Granted I suspect it's all easier to manage from VIPM.

Questions about snapshots: How are snapshots represented and stored in VIPM? Are they treated the same as other packages? You need VIPM Pro to create snapshots, is VIPM needed to use snapshots? Do you save the snapshot with your package source code in scc?

All that, *and* a tidy methodology of distributing your reuse components, *and* access to the OpenG packages too (if you use OpenG, your users already have a copy of VIPM installed, right?)

I do personally, but not for work stuff. Regardless of the licensing terms of the OpenG packages, paranoid corporate lawyers say no.

We have a formal process in place that controls how and when items get into our reuse library (we don't want just anything in there, potentialy taking down our projects, plus we don't want duplication, plus we need a controlled method of getting updates out to users, etc, etc, etc).

How involved is your process and how many developers do you have?

I'm sure Jim would butt in here and give you a billion more reasons on why SCC is so difficult to manage, but his missus Beth is currently in active labour to deliver the kingling - we're all thinking of you Jim and Beth!

Congratulations to Jim and his better half! A Kringling kingling!

[Omar Mussa]

Granted I suspect it's all easier to manage from VIPM.

In VIPM Enterprise (3.0) to deprecate a package in your repository, you just right click on the package and select 'Deprecate'. All clients connected to the repository will no longer actively convey any information about that package (however, if a VIPC file uses the package, it will still be able to download it from the repository --> deprecated is not the same as deleted).

Questions about snapshots: How are snapshots represented and stored in VIPM? Are they treated the same as other packages? You need VIPM Pro to create snapshots, is VIPM needed to use snapshots? Do you save the snapshot with your package source code in scc?

Snapshots in VIPM are called VI Package Configuration (VIPC) files. You create them by either dragging packages into the editor, or using the editor to have it scan your project and automatically detect what packages your project depends on (Requires VIPM Pro). Once you have created a VIPC file, you have created a snapshot of the packages and versions that your project depends on (and it is saved for a specific LabVIEW version based on the project you are working on). Any VIPM activation level (including Community) can apply VIPC file (double-click VIPC from within Windows or go to File-->Apply Package Configuration) --> at that point VIPM will install/upgrade/downgrade your packages to get that LabVIEW version into the specified configuration. Using VIPC files (snapshots) makes it very convenient to switch between LabVIEW projects without having to worry about what versions of reuse libraries you were using when you were last working on a given project. We are working on improving the VIPC documentation to make it easier for users to realize the full value of the VIPC files.

Since we just released VIPM 3.0 - I'll just do one shameless plug that you can find out more at jkisoft.com/vipm

[Ton Plomp]

I do personally, but not for work stuff. Regardless of the licensing terms of the OpenG packages, paranoid corporate lawyers say no.

Sorry to hear that, I wouldn't ask them about using vi.lib stuff (and just ask the lawyers if they use template letters).

What I would like to do (and most of the time do), is keeping the source of the library under SCC, and make a build that namespaces the product. Essentially that is the important thing, your reuse library is a product!

And you are it's prime client, so treat your reuse library like you would treat your commercial products.

Keeping the source and the built version seperated means I can edit the source and run tests on it without breaking existing code.

Another point is recompiles, these happens quite often in LabVIEW (a .x.1 release, patch, new .Net interface) and you will get a lot of commits that are essentially useless.

Using a distribution makes it also possible to move the code in a good way to another computer that is not networked or even from a client.

You could even use NIs installers to distribute your reuse code.

Ton

[crelf]

Breaking this off into another thread threw me into a loop. I thought maybe I had hit a time warp and it was last Thursday again.

Yeah - sorry about that - I should have made a note in the thread that it was being split.

You could depreciate a module with a scc distribution system by simply getting a previous version instead of the latest version. Once you figure out which library components a project needs you could apply an scc label to that set of components to make it easy to switch between projects. Granted I suspect it's all easier to manage from VIPM.

Well, that's not really deprecation - deprecation is whan, as the reuse library manager guy, you mark a reuse component as no-long-to-be-used-in-new-projects. This means that existing code that depend on it can still access it, but new projects need to jump through a loop to get to it (you usually only deprecate a reuse component when a new component exists that superceeds the deprecated component).

Questions about snapshots: How are snapshots represented and stored in VIPM? Are they treated the same as other packages?

You can save a snapshot of yout installed packages by creating a VI Package Configuration (VIPC). You can either embed all of the packages inside the VIPC, or (more commonly) refer to packages that exist on a common location (that's how we do it). These "snapshots" are saved on a project-by-project basis, which is great for a few reasons: we can bring a new developer onboard on a project very quickly (they just apply the VIPC for the project and they're ready to go), we can switch between projects that use different reuse library component configurations quickly, and we can put the reuse configuration for a project under SCC (great when a customer calls us three years down the track for a minor software mod - we can quickly get our LabVIEW configuration back to what it was when we originally worked on the project).

Note: all of this is now embedded in the lvproj - so when you open a project, you're prompted if you'd like to apply the VIPC for that project (if it's not already applied). Also, when you close the project, you're prompted to scan the project for any changes in the reuse components that you're using, and if you'd like to add those to the project's VIPC <- this is a very cool and important feature that you won't get from using SCC.

I do personally, but not for work stuff. Regardless of the licensing terms of the OpenG packages, paranoid corporate lawyers say no.

Awww - that's a shame. Especially since the guys did so much work to get almost everything in there under the BSD license

How involved is your process and how many developers do you have?

I can't really answer either of those questions Let's just say that it took a short amount of time to develop the process, but the it took longer to document it (we have very well-defined processes at V I Engineering, Inc. - it's something that we're extremely proud of).

Congratulations to Jim and his better half! A Kringling kingling!

I haven't heard anything in the last 12 hours or so, so let's hope that all got some sleep last night!

[Mark Yedinak]

I would highly recommend that you consider using VIPM. My group has been using source code control (CVS) for our reuse and it doesn't fully meet our needs. As crelf stated SCC doesn't truly manage your reuse libraries. The nice thing about VIPM is that once you build and deploy your packages your reuse libraries are easily integrated into the LabVIEW environment. You certainly don't want your SCC repository to sit in the users directory of LabVIEW however that is where you want you reuse libraries to exist. If you use SCC only you need to manually integrate your libraries into the user directories under the LabVIEW and this can be a pain not to mention error prone process.

[Daklu]

I appreciate the comments from everyone. I'm not the decision maker but the new use case scenarios certainly raise some questions we had not considered.

Here's a tangential question Ton alluded to: How do you manage your reuse code library's souce code for multiple Labview versions? Do you do all your dev work in the earliest version of Labview the library supports? Use "Save for previous version...?" Maintain an independent branch for each Labview version?

Since we just released VIPM 3.0 - I'll just do one shameless plug that you can find out more at jkisoft.com/vipm

Thanks for the announcement. I hadn't realized a new version was available.

Sorry to hear that, I wouldn't ask them about using vi.lib stuff (and just ask the lawyers if they use template letters).

Awww - that's a shame. Especially since the guys did so much work to get almost everything in there under the BSD license

Faceless corporate policy. However, since I'm building internal test tools as opposed to a shipping retail product, it might be okay. I haven't asked the question specifically.

What I would like to do (and most of the time do), is keeping the source of the library under SCC, and make a build that namespaces the product. Essentially that is the important thing, your reuse library is a product!

And you are it's prime client, so treat your reuse library like you would treat your commercial products.

Agreed. This is very important and not obvious to new developers. I've taken to appending the major release number to the end of the library name. (MyClass__v1.lvclass) I roll the major release number if and only if I break backwards compatibility. That lets me have multiple versions of the same package installed on a single computer, should the need ever arise.

Another point is recompiles, these happens quite often in LabVIEW (a .x.1 release, patch, new .Net interface) and you will get a lot of commits that are essentially useless.

Yep. Although I have found that using the "Treat read-only VIs as locked" and "Do not save automatic changes" options help minimize the frequent commits due to on-the-fly recompiles.

You can either embed all of the packages inside the VIPC, or (more commonly) refer to packages that exist on a common location (that's how we do it).

I assume you need a VI Package Repository license for this?

Note: all of this is now embedded in the lvproj - so when you open a project, you're prompted if you'd like to apply the VIPC for that project (if it's not already applied). Also, when you close the project, you're prompted to scan the project for any changes in the reuse components that you're using, and if you'd like to add those to the project's VIPC <- this is a very cool and important feature that you won't get from using SCC.

Slick. Very slick.

I can't really answer either of those questions

Ahhh... taking a page from NI's "Sorry, can't tell you how many developers we have working on Labview" book I see. Perhaps a drink will loosen those lips. Here... have a... VIRTUAL ROOT BEER! (Cue dramatic music.)

--------

It's not completely clear to me how the different VIPM versions fit together to form a complete system. I gather that you need at least one copy of Enterprise if you want to create your own repository, where clients will automatically check for updates to your packages. Does the computer hosting the repository have to be running VIPM Enterprise? Is there a limit to the number of repositories we can create? Say we have a development team here in the US and another team in China. Can we use a single Enterprise license to create a mirror repository for the China dev team?

The comparison chart says you can use Enterprise to create a repository, but implies you still need to purchase a VI Package Repository Client License if you want to connect to the repository. This confuses me. Is there a use case for purchasing Enterprise without purchasing a client license? Are repository client licenses shared, computer-based, or user-based?

This is how I'm seeing the pieces fitting together:

• Each repository administrator should have a license for VIPM Enterprise.
• Each reuse library developer should have a license for VIPM Pro. (Enterprise works too if the user is also the repository admin.)
• Each reuse library user should have VIPM Community, (or Pro/Enterprise) unless the user is also a project owner, in which case they will need a copy of Pro.
• Regardless of which VIPM version a developer has, each unique user should have a repository client license. (Assuming the licenses are user based.)

Suppose I have a project that I've created a vipc file for and I want to load the source code onto the target computer for testing/debugging. Does the target computer also need a repository client license?

[crelf]

How do you manage your reuse code library's souce code for multiple Labview versions? Do you do all your dev work in the earliest version of Labview the library supports? Use "Save for previous version...?" Maintain an independent branch for each Labview version?

It depends. We do most of our development in the earliest version that we need to support *in active projects*.

I assume you need a VI Package Repository license for this?

You can create VIPCs with the Professional License.

Ahhh... taking a page from NI's "Sorry, can't tell you how many developers we have working on Labview" book I see. Perhaps a drink will loosen those lips. Here... have a... VIRTUAL ROOT BEER! (Cue dramatic music.)

Geez - if it was real beer I might have thought about it

It's not completely clear to me how the different VIPM versions fit together to form a complete system. I gather that you need at least one copy of Enterprise if you want to create your own repository, where clients will automatically check for updates to your packages. Does the computer hosting the repository have to be running VIPM Enterprise? Is there a limit to the number of repositories we can create? Say we have a development team here in the US and another team in China. Can we use a single Enterprise license to create a mirror repository for the China dev team?

The enterprise license is used to *manage* the repository, and is usually on the PC of your designated librarian - there's not VIPM software on the server where your repository resides.

This is how I'm seeing the pieces fitting together:

• Each repository administrator should have a license for VIPM Enterprise.
• Each reuse library developer should have a license for VIPM Pro. (Enterprise works too if the user is also the repository admin.)
• Each reuse library user should have VIPM Community, (or Pro/Enterprise) unless the user is also a project owner, in which case they will need a copy of Pro.

That looks right to me.

[Daklu]

But, problem unsolved: how to get my team working with it/benefit from it?

In my experience if you want to change your team's behavior you have to identify what issues cause them pain and show them how the new behavior will avoid that pain. If your team doesn't experience any pain with the current system they're not likely to want to change to something new.

You can either embed all of the packages inside the VIPC, or (more commonly) refer to packages that exist on a common location (that's how we do it).

I assume you need a VI Package Repository license for this?

You can create VIPCs with the Professional License.

Yes, but can you create VIPCs that link to packages at an arbitrary network location or when using that feature do they have to link to a 'real' package repository, which implies a repository client license is needed.

[Omar Mussa]

Yes, but can you create VIPCs that link to packages at an arbitrary network location or when using that feature do they have to link to a 'real' package repository, which implies a repository client license is needed.

If you link to the package in the VIPC instead of embedding it, the package needs to be on a VI Package Repository and you must have a VIPM Client license to access that repository (unless the package is distributed through the VI Package Network like the OpenG/JKI packages are -- we plan on eventually opening up the VI Package Network to others but we're still working on several issues that prevent this from happening at this time).

[crelf]

If you link to the package in the VIPC instead of embedding it, the package needs to be on a VI Package Repository and you must have a VIPM Client license to access that repository

That must be a new feature - our VIPCs rarely have their packages inside them: they usually point to a location on a newtork server. Say I'm not using the enterprise edition to manage a repository: can I still have my VIPCs point to network location(s)?