Showing results for 
Search instead for 
Did you mean: 

What Source Control Provider would you recommend for a single developer on a moderately large labVIEW project

Go to solution

I have not used a Source Control Provider before.  My hope is that I don't have to face a big learning curve in using the basic features of a source control provider.  

Also curious what is the most popular provider used by LabVIEW developers.

Thank you.

0 Kudos
Message 1 of 12

As far as simple to figure out, I highly recommend Tortoise SVN.  I currently use BitBucket with GIT and Source Tree.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 12
Tortoise SVN is an excellent choice for a project of any size. Tortoise allows you to setup a repository on any connected drive without the overhead of a dedicated server.


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 3 of 12
Accepted by topic author WRB

If you are getting started with Subversion (Tortoise SVN is the "client" for a Subversion Server), you have a choice of three options:

  1. Use a Subversion Server maintained by your Company or University.  (I, fortunately, have one available to me).
  2. Use a Commercial Subversion Server.
  3. "Roll your own" (meaning either host a Server yourself, on your PC or on another PC, or simply use a "local repository").

I've listed them in the order of (in my opinion) "desirability".  I would, myself, go to fairly great lengths to avoid Option 3, as it puts all of the "eggs in the same basket", that is, you have to take responsibility for not only keeping your code Committed/Updated to the Repository, but you need to keep the Repository safe, backed up, and "remote" (if your house burns down and the external drive holding the Repository also goes up in flames,  you've lost everything).


I recently started a collaboration with a colleague in Canada.  Due to institutional policies, I couldn't provide access to our local Subversion Server, but found that Assembla ( offered Subversion Server access at quite a reasonable cost.


Once you have identified a Server, getting your Repository created and your Project saved in the Repository isn't too difficult.  A practice I've found works well is to organize the Repository by LabVIEW Projects, one Project per Repository, with the Repository name being the name of the Project.  I've adopted the trunk/branches/tags subfolder model for the Repository (that is, the Repository "Bob's Project" will have a trunk, a branches, and a tags sub-folder), with almost all of the activity taking place in the trunk.  I try to almost never use branches, but that's another story.


There are a number of tools to put "hooks" into Subversion within LabVIEW.  My personal preference is to do all of my Subversion work at the level of Windows File Explorer, committing and updating entire Projects at the end and beginning of work sessions (commit at end, update at beginning).


Bob Schor 

Message 4 of 12

Thank you very much for the detailed advice. 

Short term I'll go for using a local dedicated server (one of your "roll your own" suggestions) - this will be a vast improvement over my past practices.

BTW - I just purchased "TortoiseSVN Beginner's Guide" from Amazon - it looks good for getting me up to speed.


0 Kudos
Message 5 of 12

I go with TortoiseGit on Gitlab and seems to work fine. Onyl downside is that you don't have a toolkit for git similar to svn in LabVIEW. Plus Gitlab is free and private, which is nice.

Engage! using LV2015
Message 6 of 12

In one of my projects we used ProjectLocker as external code repository, it seemed quite ok.


G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
0 Kudos
Message 7 of 12

Another vote for SVN.  I use VisualSVN running on a server we have access to, but it could just be any always on computer, or running from local host.  The basics of it are very easy to use.  Create repositories, create users (or user) and then use TortoiseSVN as the client connecting to that server.  The free version does everything I need.

0 Kudos
Message 8 of 12

Another vote for git.  It can be serverless if you want.  Gitlab is free and private, as mentioned.  I have used Assembla, and it's OK, but I did find it a bit slow. I think it has a 1GB limit on their free service.


Git can also continue to work if you don't have access to the server.  This has happened to me on customer sites, but even if my network goes down, I can still use it.


The Tortoise clients make it very nice and easy to use any of the major open source SCC's.  Just integrates into explorer, and you don't have to memorize all the commands.  For most day-to-day stuff, you won't need anything else.  There have been a few times were I had to open up a bash window and manually do some commands to fix a problem.


I used the built-in LabVIEW provider with Perforce I believe and found the whole experience a bit clunky some years ago.

0 Kudos
Message 9 of 12

@Matthew_Kelton wrote:


I used the built-in LabVIEW provider with Perforce I believe and found the whole experience a bit clunky some years ago.

It hasn't changed.  There does exist an explorer plugin for Perforce that makes some of the basic operations work semi-easily like it does with the tortoise clients.

0 Kudos
Message 10 of 12