I found myself in the same situation as you a while back. (this was before the VIPM came out, if it had existed at the time we probably would have used it)
We (a team of researchers within a larger organization) where and are doing dedicated, institute specific modules in labview for integrating NI equipment in an existing infrastructure.
This has after several projects and years of development turned into a framework that we now (try to
) maintain (and update).
To find a easy way of distributing this framework to all the "users" we also thought that svn could get the job done in an easy way even dough it is kind of slow and has strange behavior from time to time (i guess the perks we get are more user related than by the versioning system itself)
What we did was the following:
First for the framework developers we agreed on an naming syntax and structure on the repository (using the typical "trunk", "tags" and "branch") where everything stored in the "tags" folder/repository should be considered a release and never modified. If one finds a bug, the tag is copied into branch, fixed, and then re-published as a bug/minor fix (plus the fix if applicable is fixed in the trunk). Sometimes we fix things directly in the trunk but it might have advanced beyond the released version that needs fixing so branching is necessary. The tags released libraries/tools would have the folder structure, menu files and resources needed for direct integration into the labview file/folder structure. - This "solves" the problem of someone committing partially working code.
Second we created a simple svn installer (at first by simply using the system exec in labview to execute svn commands in the terminal but later by making a light weight svn client in c++/c and using the labview external code node) that would do a svn export and not a svn checkout. We did this to avoid users having all the .svn synch stuff in their labview development environment (remember these guys are researchers, meaning if they can they will fiddle with absolutely everything and of course break it at some point
The Installer stores all needed info in a config file with the modules in user.lib or wherever it is installed. In this file we keep track of where/when/what is installed, versions, vis/files etc. and every time the users launch labview we run the installer in background doing a quick check if there are any new versions of the modules they have installed and if so give them a prompt to install the latest release. if the file is deleted we do a "recursive list folder" in the most common install locations and if we find some "naming conflicts" we try to sort these out (we try to use .lvlib and .llb "containers" to avoid this but it still doesn't work 100% )
The installer checks various things and tries to cope with it (local modifications, custom installation location, changes in palette .mnu file etc) and there are surely many perks to sort out but in general i would say it does what we expect it to do and ease the job of distributing the framework.
- I guess what i am trying to say here is that in essence a simple installer can easily be realized using svn, and if the environment you are targeting is well known you might pull it off with just a few hours of work. On the other hand if you have several users and have to cope with all the unforeseen/unique things in their environments, you might be better off selecting a "off the shelve" installer (like the VIPM) that has all ready solved many of these problems (dough i do find fiddling with these problems fun from time to time