LabVIEW
Subversion SCC and reusable code
So I'm finally implementing source code control. We currently have one LV dev but are looking at expansion soon. I've never used any SCC at all, and it looks like Subversion is the "simplest" one to get started with. Right now I'm planning on using TortoiseSVN on my work computer and VisualSVN on our file server (let me know if I'm doing this wrong... I'm new!) I will also say I've been trying to read as much as possible, but a LOT of the content out there is VERY old, and I'm not certain it all still applies.
My question regards repositories and reusable code. I have a library of hardware drivers I've written to control a bunch of hardware. I use this library in multiple projects. How do I handle the structuring of my SCC with respect to both the individual projects I'm working on and the reusable driver code? Do I need multiple repositories?
I can imagine needing a different repository for each project and one for the reusable driver code. Or I can imagine a single repository for all of my stuff, with a separate trunk for each project and one for my reusable driver code. Which one of those, if either, is correct?
Also, I can see having an issue where I write Program A using Driver Library v1. Later, I write Program B, and need to add some features to the driver library, resulting in Driver Library v2. Let's assume v2 is incompatible with v1, and I need to fix a bug in Program A. Currently (without SCC) I'd have to refactor Program A to use Driver Library v2 to fix any small bug. Would I be able to have Program A look at Driver Library v1 (an old version of the shared driver library) using the source code manager?
I guess I'm having trouble in general getting my head around SCC as it pertains to LV development with all of the reusable code segments/classes/project libraries/lvlibs/etc. I can see how it will work for a single straightforward project, but when projects reuse the same code, I start to get a bit lost.
I'd love any advice or help on this, and further reading would be great. I've read a good many articles already but much of it is nearly 10 years old, and I'm certain the tides have changed since many of those articles have been written.
1. Your reuse library should be maintained in its own repository.
2. You really should look into VI Package Manager (VIPM). It actually comes with the recent versions of LabVIEW (at least as far back as 2012). But the idea is that you build packages of your reuse library. Then you install the ones you need for that project. These do not end up in your project repositories. But you could have copies of the packages in the projects just so you know what you have to install. Or if you go with the Professional version of VIPM, you can build package configurations. Then you just keep the configuration with the project. The configuration will keep track of the packages that need to be installed for that project.
Congratulations! You've made the most important step: start using SCC. It will change your world. You'll get used to the basics in no time.
I wouldn't say SVN is easier then Hg, they are just fundamentally different (centralised vs distributed I think). GIT is more or less a marriage between the two (functionally), and might be a bit more intimidating, but more flexible.
I'm having the same problem with the documentation. It's all very detailed and technical without telling why you even want to do it, or if you should do it. It usually jumps directly to command line stuff, witch is very intimidating. A lot of standard stuff can be done with Tortoise (SVN, GIT and Hg), but good beginners tutorials are rare.
I'd start with simply copying the drivers to each project, until you are completely comfortable with all other SCC aspects. Once you know about branching, tagging, merging, etc., you'll have a better perspective on the advanced stuff.
I'd say there are three options: (temporarily) ignoring the problem, nesting the repo's (not good?), and using externals. The first goes a long way, especially when your team is small.
Search LabVIEW like a graph! 
We also use VisualSVN on a server, and TortoiseSVN as the clients. VisualSVN is pretty simple for making users and repositories.
As for shared common code, will recommend VIPM as well. I have a repository for the reuse source which I make changes to and build into a package. These packages are then collected into a VIPC which is a single file that contains multiple VIPM packages. This one VIPC file can be taken on a USB drive and all dependencies (internal, and external, OpenG, NI packages, MGI packages, etc) can be installed all at once. This installs reuse code in the user.lib for a version of LabVIEW. Each user, and each install of LabVIEW gets its own copy.
Then you might have questions about versioning on the packages. Well you can scan your project and it will tell you what packages are used, and what versions and that can be saved as a VIPC as well which can go into SCC for that project.
So in a perfect world it works like this. Make changes to reuse repository, build reuse version 1.0 VIPC which is made up of a bunch of packages all with their own versions. Make changes to the project repository using some of the reuse functions from your palette which comes from the installed packages. Periodically scan your project creating a VIPC of the project saving it in the project repository (this goes along with the project like source)
Now years later someone says "hey remember that program you haven't thought about in years, we need found a bug and it needs fixing". Then using SVN you roll your project back to the commit you want, and you apply the VIPC found with the source. This will install the packages for that project, used at that time. Now open the old source that your rolled back to and you should have the same source as when that code was last worked on. This doesn't include things like DAQmx versions, of course and to get into capturing that information maybe a VM would be more appropriate.
Also note that making VIPCs, and scanning a project is pro versions of VIPM but the free versions still allow you to make packages and build them.
This is all a lot to take in so take baby steps and get SCC going but know that there are better ways of doing reuse. If you made a shared repository of reuse and just link your project code to that, then you have an issue with the subVI paths being relative and other users need to have the same relative paths. Where with VIPM packages all the code is found under vi.lib or user.lib wherever you install it. This also takes care of the muliple versions of LabVIEW issue since reuse is installed for each version of LabVIEW, instead of having one repository all users use, on all versions of LabVIEW which might get up saved and break things. This also doesn't do well for version management since a user might make a change to the reuse, and another will perform an update which could break their code and not know why, or how to fix it. Packages help make a line in the sand where code has been tested and versionsed, so even if things do break, just keep the older package installed.
@Bob_Schor wrote:
Bert,
I'm "on the same page" with the other responders, except I haven't (yet) gotten around to incorporating my "re-use" libraries into VIPM (though it's high on my list of "things to do".
I'm not on that page per sé. I want my code to be in my project, not in user.lib or vi.lib. I haven't looked into VIPM for a while, but I think I'll only keep using it for external packages. For internal libraries, I'm more leaning towards external repo's. The difference is that when everything is under my project, everything is under one directory that I can copy (and commit) without worrying about missing parts. I'm not sure if VIPM has a way around this or not, but this would be a deal breaker for me. I might be very wrong (feel free to enlighten me)...
@dan_u wrote:
@Bob_Schor wrote:
That's precisely what l'm doing now. Each project has its own repository, and I have copies of my common routines within the project.
Bob Schor
I think that's not the same. SVN Externals loads files from another repository into the current one. No copies, just referencing the code from the externals repository. So you can create a repository containing reusable code, and link that via svn externals into your actual projects.
This also addresses another question from the OP: when you change the reusable code in a way that would break code from another project, you can link to a specific revision of the external repository (instead of the head revision).
That might also be useful if you lift the reuse code repo to a newer LV version, but keep some projects in the older LV version.
Probably a good idea to keep the library development version in the trunk, and keep newer LV versions in branches. If you commit newer LV versions in the trunk, how else are to going to do code changes in the older version?
Thanks everyone for all of the responses. I've been busy this week just trying to get the core SVN "experience" going, which has gone well so far.
It sounds like I have a couple of options, the first being to use SVN externals- which I don't understand yet and will need to read up on, or to use VIPM. VIPM Pro is going to be a no-go for right now for cost reasons, but my dependencies aren't super complicated at the moment.
I'm having a bit of trouble wrapping my head around the packages and how they're handled in source control. Let me see if I can sum up what I'd need to do- and please correct me if I'm wrong. I have only had experience using VIPM for downloading random packages from the internet, so I'm not totally sure I have a handle on how packages work in practice. Let me know if the following sounds correct:
-Have my reuse library in its own repo. When I have a version ready to use, I make a tag, and generate a package using VIPM. This generates a single file (a package) containing the reuse code at that point in development.
-This package file goes into the _project_ repo, and is maintained as part of the project. When I'm finished with the project, I can uninstall that package if I want, but the package file itself is committed along with the project source code into the project repository.
-Later I need to do some edits to the project, and the reuse library has "moved on" to newer versions. I can simply roll back my main project repo and install the package saved there and do the bug fix/upgrades/whatever. At this point I don't look at the shared code repo, only at the VIPM-generated package file stored with my project repo.
Does that sound right? I'm going to read up on SVN externals, which initially sounds like I can access multiple repositories at once, is that right? If so- can I do different commits to each repo, or only in my main one?
With externals, you can mark files\dirs in you're repo as early. To this means you can choose to update\commit\revert\etc. this repo independently form he 'main' repo. I don't think it's more then that. The external repo files still end up in he main repo, so you will have all revision history and 100% certency you can revert to a previous revision. If a driver is in vi.lib or user.lib, you don't have this certency.
I'll repeat this advise. You can live with ignoring this issue. Simply copy libs. There will be no link to the lib repo and he project repo. I understand it's not ideal, but it's no big deal. You can consider it the icing on the cake.
