Leaderboard

Yes, I tried sub-modules and decided against them. Not sure about Hg or SVN The obvious reason to use sub-modules is to maintain some "common" repository for use in multiple projects. The OpenG libraries are a perfect example of such libraries. Unfortunately there are a some things which made them less useful to me than first thought: 1. Folder hierarchy Each of those libraries are organized in their own hierarchy of folders, most of which you don't need in your current project. In my case everything is organized in LabVIEW projects using virtual folders where the actual hierarchy on disk is much less complex (typically one folder for each library). So, when reusing a library it would be great to get the same hierarchy in the "owning" project in order to maintain consistency. Since my reuse libraries are organized without library files (*.lvlib), they are just a bunch of VIs on disk, which makes them hard to import into each project because I would have to recreate the hierarchy over and over again. VI packages solve this problem elegantly in my case. 2. Palettes Reusable libraries commonly provide a bunch of VIs, most of which you don't (or shouldn't) use in the owning project. One great example is the array manipulation palette of the OpenG libraries which contains a lot of instances for few polymorphic VIs. Being able to select between a few polymorphic VIs on a palette is way easier than searching through the project to find the appropriate VI. For QuickDrop users like me the search function is very useful. By having all polymorphic instances in the project the search results are useless as all instances are returned as results (depending on the naming schema). Without palettes everyone is forced to search through the project, which is very time consuming. 3. Maintenance The ability to change code "on the fly". You can fix bugs during development of your own project and therefore improve multiple projects at once. While this is true there is also a great chance to break consistency between projects because someone decided to do an "improvement" that is incompatible to other projects. This is actually my main reason against sub-modules. Example: Add VIs from a sub-module to a library file in the owning project, push the sub-module, pull it into another project, welcome to coding hell. 4. Independence: By splitting reuse libraries into separate repositories and providing them as packages you gain control over each one of those libraries individually. During development of those libraries you can focus on the tasks it is supposed to do instead of having to consider the "big picture". In my experience this is a big burden taken from the shoulders of each developer. I already have to consider about 1k+ VIs in a single project while I don't have to consider the 1.5k+ VIs in our reuse libraries. And these are just "tiny" projects compared to the ones I have seen others do. When one of our reuse libraries is missing a feature I do a feature request. When something is not working as expected I do a bug report. Both of which can be implemented and analyzed on their own pace. If I need them done "now", I'll take charge of the feature request or bug report myself. Of course these are just my experiences based on our workflow. It could be an entirely different case for you.

NextLabVIEWStand confirmed!