Reasons for personal source code control
In Jim Kring's top 5 bad excuses for not using source code control post, someone commented
Perhaps another top five is needed - “reasons a single LabVIEW developer should use scc software” - then we could decide for ourselves how our manual methods stack up.
So here's my top 5
1. It forces you to document what you changed
Each time I check in/commit a set of VIs, the SCC program (+ LabVIEW if I enable it) asks me to describe my changes. It's invaluable to have a running history of the changes you made to your code, both what you said you changed and what VIs actually were different. Here's an example from one of my personal projects
- #1 - "Initial version"
- #2 - "Fixed link to Open URL in Browser. It isn't in vi.lib so the paths get all messed up as soon as you move this llb somewhere else"
- #3 - "Changed name of LLB and help directory. Added quoting to the URL sent to OpenURL"
- #4 - "Added flashing of dots on refresh. Enhanced the help slightly. Will add to the help in the next changelist"
- #5 - "Added examples and 2 more pictures to the docs"
- #6 - "Completed help and examples - pre final review"
That code was written in November 2001 and by looking at that brief history, it takes me back through what I was doing.
2. It tracks code in multiple areas with ease
Code that spans multiple folder hierarchies on disk can be a problem for the "make a copy as a backup" technique. Good source code management systems can track code spread across your disk. Did you put code in user.lib and in your documents & settings area? No problem. As soon as you have code in more than one directory, I question how meticulous you will be about copying "everything". Instead, you'll start getting lazy which takes us to #3.
3. You can always revert to a good (or at least known) state
If something goes horribly wrong, I do a "save" rather than "save as..." and nuke a VI, I can always recover to something known. It can be accomplished in 3 mouse clicks rather than searching around on the hard drive. For SCM systems that are "changelist" based (such as CVS, Subversion, and Perforce), you can pull from a particular known good state. "Give me what I submitted on 5/21/2007" and you know those VIs actually work together. That's why one of the "good scm practices" is to put EVERYTHING that could change under SCM.
4. You can get everything back 6 months from now
This is another version of #2 & #3. Suppose your nifty user.lib extension changes 4 months from now. Can you rebuild your nice little utility that used an older version? Do you even have that older version of the extension any more? Keep everything that could change under SCM, including the OpenG tools that you get from Jim and you can always roll your environment back to the way it was 6 months ago and have a clean rebuild. We put our C++ compiler under SCM here at NI so if we need to rebuild LabVIEW 8.0.1 for some reason, we can make sure we are using the exact same build environment as when we first built it.
5. Allows you to track your components
You got those nifty OpenG tools and you (gasp) modified a VI! How do you keep track of those changes? What happens when they upgrade those components? How do you make sure you go re-modify the source with your changes? Manual record-keeping is not your friend here.
6. More disk efficient
Maybe in this age of big hard drives, this isn't an issue. But how many times are you going to make a duplicate of a 30 meg folder hierarchy because you changed one VI. Do you stop and say "maybe not, I'll do it later". That goes through my head.
Labels: CodingStyle, LabVIEW, Software Development
posted by Joel @ 3:18 PM
7 comments
