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:
I read over your blog, and i found it inquisitive, you may find My Blog interesting. So please Click Here To Read My Blog
http://ajomonteiro.blogspot.com
Can you elaborate more about #2,
"It tracks code in multiple areas with ease ...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? "
Exactly how does one go about doing this? Does one put the entire LabVIEW directory under revision control (to capture the various instrument drivers, etc., as well as the c:\vxipnp\ directory?
Does this mean that everyone involved in a project has to have the same configuration (same LabView directory, etc?). Or is there another way to keep track of these other files? I had been thinking that they could be included in the project directory , perhaps as an "externals" (I am a subversion user). Some comments from someone who has "been there, done that" would be very helpful
It depends upon the source code control system but typically, you would not have to put your entire LabVIEW directory under source code control. In Perforce, for example, you have the concept of a "client". You could set up your client to track files in
C:\dev\this\project
c:\dev\that\project
c:\Program Files\National Instruments\LabVIEW 7.1\user.lib
Additionally you map each directory on your hard drive to some area of the source code database and that area has a name. This allows another person to check out the code to
d:\mystuff\this_project
d:\someotherdir\that_project
e:\Programs\LabVIEW 7.1\user.lib
Subversion allows this capability also.
Of course, this means that everyone must have the same user.lib (or at least a common subfolder of user.lib). If they don't, maybe you should store your common vis somewhere else.
Subversion also allows this capability, though I like the way Perforce allows you to "sync entire client" to make sure that your this_project and your user.lib are always up to date.
Perforce cost hundreds dollars per client. Subversion is not integrated in LabVIEW.
So it's better to forget about SCC for now.
Since I was referring to "personal" source code control, I will point out that Perforce is free for personal use. You can create one user and 3 "client specs" with the free license.
Hi,
What is for you the best SCC?
At work we use MS Sourcesafe
Or is zipping in a project a better way?
Prior to being at NI, I used Visual Source Safe in a commercial C++ environment from 1996-1998. Then we switched to CVS and I worked with that for a year. At NI we use Perforce internally so I've worked with it for 8 years. In order of preference I'd say
#1 Perforce
#2 CVS
#3 VSS
#4 manually zipping projects
So, VSS is better than nothing but back in 1997 I had a lot of problems with it so I avoid it. I haven't seen anything better than Perforce for a commercial environment. Subversion may be better than CVS but I just haven't worked with it enough to be able to say. I have liked Subversion when I've used it though. I've found CVS to be powerful and robust but it's ease of use leaves a lot to be desired.
Post a Comment
<< Home