Top 5 bad excuses for not using source code control

Posted on Sunday 17 June 2007

apples and orangesSource code control tools are important for anyone working on projects with files stored on computers, especially software developers. They help you to have a record of every version of every file in your project, and make those files available to multiple developers working in a distributed environment. Many people have excuses for not using source code control tools, but with so many great and free tools available, these excuses are simply unfounded in reality.

Here is a short list of the top 5 bad excuses for not using source code control (and the reality behind why these excuses shouldn’t be holding you back):

1) I’m just one person, so I don’t need source code control.

Reality: Single developers make mistakes all the time. And, they can easily benefit from being able to restore from any revision of their sources and to see a descriptive log of changes. Also, source control tools make development on more than one computer easy (consider your office computer, laptop, and those few lab computers).

2) Source code control tools are expensive and I can’t afford them.

Reality: There are great free tools. For example, subversion (and the TortoiseSVN client), CVS (and the TortoiseCVS client) are free. Also, Perforce, a commercial product, has a free version that limits the number of user accounts.

3) I don’t have a server computer or any IT support (or desire to have them support me).

Reality: With TortoiseSVN (and others) you can create a “local repository” on your hard drive, so you don’t even need a server. Give it a try — it’s easy.

4) I already have a simple folder backup/archiving scheme in place.

Reality: Once you start using a version control tool you will realize that it basically does exactly what your folder archiving scheme does, but also does a lot more and a better job of it. Your folder backup scheme is prone to human error. And, trying to figure out differences between versions is pretty complicated, too. Also, how do you backup your folder backups/archive? With a source code control system you have a single central repository that can be backed up. (Note: if you are committed to using a folder backup scheme you should definitely take a look at Beyond Compare for comparing folders and files.)

5) I don’t understand the concepts of source code control.

Reality: Learning these concepts is important. You’re already doing these activities, you just don’t realize it and your probably not doing a great job at it. If you’d like to learn more about the concepts of source code control, then you should definitely read Eric Sink’s Source Control HOWTO.

Also, TortoiseSVN is easy to use — it integrates directly into Windows Explorer. You simply right-click on your files/folders to perform operations. And, your files/folders icons change to reflect their state in the source code control system (modified, not under version control, etc.).

Apples and oranges photo courtesy of Dano.

Using Subversion in LabVIEW? The JKI TortoiseSVN Tool for LabVIEW makes it easy by letting you use TortoiseSVN from inside your LabVIEW Projects and VIs.

Subversion and LabVIEW in the Enterprise : If your organization uses LabVIEW and you would like help deploying Subversion in your organization, consider hiring JKI to help get you started. You can contact us via our website.


10 Comments for 'Top 5 bad excuses for not using source code control'

  1.  
    crelf
    June 17, 2007 | 1:49 pm
     

    Love it! Maybe this article should be renamed “Bottom five reasons for not using source code control” :D

  2.  
    Tom Hawkins
    June 18, 2007 | 2:16 am
     

    I know excuses 1-4 are no good and I do understand the basic concepts like checking out and in, but I could still do with an example tutorial of how to apply it to LabVIEW. How do people handle VI’s common to several projects such as the contents of instr.lib and user.lib? What’s the procedure for opening up a project built with earlier versions of those VI’s? Does the ‘merge’ concept make any sense in LabVIEW? And so on.

    I recently came across a piece of software that might be useful for the single developer/single machine case. I haven’t tried it yet but Versomatic claims to automatically save a version history for every file you edit and let you revert to previous versions:
    http://www.acertant.com/web/versomatic/

  3.  
    June 18, 2007 | 5:47 am
     

    I’m going to disagree with the explicit content of this article while agreeing with one of its subtexts: we all actually DO already use some form of Source Code Control. The question is really — is it more helplful to use a separate software package to implement Source Code Control, esp if you are a single developer? IME the answer to the second question can be: no, it isn’t more useful. But that is also my personal experience FWIW.

  4.  
    June 18, 2007 | 9:06 am
     

    Tom,

    Thanks for the comments. I’ll consider putting some kind of example together. You might also want to read the following:

    * Controlling VI Development — Using Third-Party Source and Version Control Software with LabVIEW
    * Using Source Control Software with LabVIEW

    One thing that I discovered (and had to struggle with for a little while) when I first switched from using Visual Source Safe to CVS was check-in/check-out is an overly constrained system for version control. Actually, the commit/update (with merging and conflict resolution) is much more flexible and caters to how people naturally want to work asynchronously with other developers. Yes, merging does make sense in LabVIEW. Check out LVDiff, a tool that allows integration between source code control and LabVIEW’s side-by-side VI comparison tool.

    Regarding how to handle VI’s that are common to several project, JKI uses VI Package Manager (VIPM) to install and configuration manage reuse libraries. We use VIPM for our in-house reuse libraries in the same way that we use it for downloading and installing the OpenG tools. VIPM 1.1 is going to introduce the concept of a package configuration which can be kept for each project, which allows you to reconfigure LabVIEW before working on that project — it’s very cool and we have been using it internally for some time, now.

    Thanks for the link to versomatic. I’ve seen similar programs before and they are really nice for saving backups of every file. One thing that I believe these tools all lack is the ability to do branching, merging, diffing, etc. However, I think that they might be a good solution for some poeple.

    By the way, the next LabVIEW release (following 8.2) is going to add even more support for source code control tools. I’ve seen some NI patents pop up that relate to merging ;)

    Thanks,

    -Jim

  5.  
    June 18, 2007 | 9:18 am
     

    drval,

    Yes, we are all entitled to our opinions and perspectives — thanks for sharing yours :)

    I did say that people are already performing various source code control operations manually, so I agree with you that “we all actually DO already use some form of Source Code Control.”

    Regarding the question of whether a single developer is more effective with or without source code control, this certainly depends on the person, the source code control tools, and the nature of the software project. However, in my experience I have found that I am an order of magnitude more effective when using source code control tools such as TortoiseSVN and LVDiff.

    Thanks,

    -Jim

  6.  
    CBL
    June 18, 2007 | 1:39 pm
     

    Good stuff – using scc software as a single developer is one of those things where you want to make your decision based on knowledge. If you decide not to use scc software, you better have a good explanation for that decision.
    It is all about becoming a more capable developer, and TortoiseSVN certainly helps in that regard. 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.

  7.  
    June 18, 2007 | 3:41 pm
     

    CBL: I like your idea for an article on the “top five reasons a single LabVIEW developer should use scc software” (heck, it might even turn into a top-ten). I’m on it :)

  8.  
    June 19, 2007 | 3:19 pm
     

    Here’s my version of “top five reasons a single developer should use SCC.” I’m curious to see Jim’s

    http://ideasinwiring.blogspot.com/2007/06/reasons-for-personal-source-code.html

  9.  
    Mikael Holmström
    July 24, 2007 | 9:45 pm
     

    Jim,
    You have great experience of SVN and we’re using it for att our source code right now (via TortoiseSVN client), but it says that CVS handles binary data better (i.e. LabVIEW VIs).
    Any comments?
    //Mikael

  10.  
    July 24, 2007 | 10:04 pm
     

    Mikael,

    I’m happy to hear that you’re using SVN. I hope that it serves you well :)

    I’m not sure what information you’re referring to that says CVS handles binary data better than SVN. In fact, I’m pretty sure that SVN is better in this regard, since SVN transmits and stores binary differences between successive file revisions, which is much more efficient for both data transfer and repository storage.

    Here are a couple good comparisons that I found:

    * SVN vs CVS quick comparison
    * http://www.sesp.cse.clrc.ac.uk/Publications/cvs-svn/cvs-svn.pdf

    -Jim

Leave a comment

(required)

(required)


Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.


RSS feed for comments on this post |

 

Bad Behavior has blocked 5049 access attempts in the last 7 days.