Working in a team on several computers, and need to make sure all subvi's are available

[gpsmith]

I'm working on a team project, and we are using a Dropbox account to share the vi information.  We've had a few instances where one user writes a program, and then when another user accesses the work, they get hit with a bunch of "missing vi" errors.

Instead of searching over and over again every time something new gets added, is there a way to have labview copy all the subvis a particular program is using into a single file.  I'm pretty sure the answer will be "create a library" but I'm not sure if that's the right path, and if so, how to do that semiatuomatically...

Thanks!

[ToeCutter]

You can create a library, but the best way to do this is with some form of version control system, e.g. 'Subversion'.

http://www.visualsvn.com/server/ (free server, Windows)

http://tortoisesvn.net/ (free client, Windows)

[Bob_Schor]

Even when a single developer (such as I) develop LabVIEW from multiple machines (such as my development machine at work, my laptop at home, and the machine to which the code will be deployed), a Version Control System is definitely the Way to Go (and even more so if there are multiple team members).  I've used (and really like) Subversion for several years -- my only caveat was going to be "but you need to find or build a Repository (server)", but Toe Cutter has provided a "Do it Yourself" link to building your own Windows server -- all you now need is a location that all of your team can access.

If Subversion doesn't work for you, do check out other Version Control Systems to see if they work for your team.

[billko]

Can't you just use Tortoise SVN to create your repository?

[gpsmith]

I'd agree that's a good solution for something that's living beyond the next few weeks.  Perhaps a better way to ask the question would be "is there a way to trace all the dependncies of a vi"

We have several reference vis that have been modified, but when the others look at them (to get a sense of the outputs for further down the line in another VI), not everybody has the same libraries installed.  If we're just wanting to make sure al lthe dependencies are stored on the shared acount, is there a way beyond simply opening every vi to see what's in there?

[billko]

---

@gpsmith wrote:

I'd agree that's a good solution for something that's living beyond the next few weeks.  Perhaps a better way to ask the question would be "is there a way to trace all the dependncies of a vi"

We have several reference vis that have been modified, but when the others look at them (to get a sense of the outputs for further down the line in another VI), not everybody has the same libraries installed.  If we're just wanting to make sure al lthe dependencies are stored on the shared acount, is there a way beyond simply opening every vi to see what's in there?

---

Perhaps a better way of answering it is:

Are you willing to recreate the past few weeks if something catastrophic happens?

[MarcDub]

I cannot recommend enough the use of a code control system for all the reasons given above and more. I have been using Subversion for a few years and it really makes life simpler if you work on a team or alone on several computers (I've done both). Installing the server is not that complicated. However, if you don't want to bother with the installation of a server, there are several free online services. The online service has the additional advantage that you can work with remote team members, and you can transparently work from your work computer to your home computer.

[Bob_Schor]

I use the follwing "trick" (whick I learned from a LabVIEW 7 programmer, way before LabVIEW Project).

First, always use LabVIEW Project, and make sure that all of the VIs that you develop are saved in the Project.  If you are working on "isolated projjects" (meaning they do not "share" common copies of VIs, but have their own unique set), then a reasonable way to organze your Project is to create a Windows Folder to hold the Project, creating sub-folders corresponding to whatever divisions you normally use (I have folders called Util, Types, Documentation, Hardware, DAQ, etc., with the top level VI typically outside the subfolders).  I then create my Project with virtual folders that match the physical ones (allowing me to "be lazy" and create auto-populating folders, but I typically turn off this feature).

Now here's the trick -- create a VI (which I call a Tree) that contains every VI in your Project.  [To help me organize the Tree, I group VIs according to my folders, and sort them alphabetically so they correspond to the order in both the physical folder and the Project].  Note that you really want to have made icons for all of your VIs otherwise your Tree will be messy to maintain.

Normally, you don't open the Tree.  However, when you want to find "Where did I use the "Find Stuff" VI in my Project?", open the Tree, open Find Stuff, and do a "Show All Instances.  If you never used it, it will immediately "jump" to the Tree (as that's the only place it exists), and you'll know it is a candidate for removal (as it isn't being used).  This technique really helps when you have several hundred VIs, some of which are "evolving" and getting replaced ...

[dsavir]

Fist let me add my vote for TortoiseSVN, or another version of source control. Dropbox is good for synchronization, but you can't rollback, log and merge with it.

However, if you really just want a list of paths and project items, you can load all the project items and get their paths using VI scripting. I attached my version. Top level VI is check Project Paths. I use OpenG libraries , so you might need to modify, but what I basically did was:

1. Get all project items

2. Remove from array all items that are in vi.lib and in project folder (which I assume is your dropbox folder)

3. Show all remaining VI paths

4. Show caller for each VI

See if this helps you.

Danielle