Comments on: Top 5 bad excuses for not using source code control

By: Jim Kring

Jim Kring — Wed, 25 Jul 2007 05:04:06 +0000

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

By: Mikael Holmström

Mikael Holmström — Wed, 25 Jul 2007 04:45:55 +0000

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

By: Joel Sumner

Joel Sumner — Tue, 19 Jun 2007 22:19:19 +0000

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

By: Jim Kring

Jim Kring — Mon, 18 Jun 2007 22:41:56 +0000

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

By: CBL

CBL — Mon, 18 Jun 2007 20:39:15 +0000

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.

By: Jim Kring

Jim Kring — Mon, 18 Jun 2007 16:18:23 +0000

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

By: Jim Kring

Jim Kring — Mon, 18 Jun 2007 16:06:08 +0000

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

By: drval

drval — Mon, 18 Jun 2007 12:47:07 +0000

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.

By: Tom Hawkins

Tom Hawkins — Mon, 18 Jun 2007 09:16:34 +0000

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/

By: crelf

crelf — Sun, 17 Jun 2007 20:49:41 +0000

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