Source code control Recommendation for LabVIEW

[SB_123]

Hi,

I have been using LabVIEW for a while (mainly for standalone application in Lab Settings to automate some DAQ operation for test). Therefore, I never bothered about source code control. But, now I started working on projects where I start seeing need to have a source code control. I have used Git in the past for text based programming but I do not know how well it will work with LabVIEW. 

What source code control is used most commonly for LabVIEW? if someone can direct me to appropriate resources so that I can start looking into it and use it, I would highly appreciate it. 

FYI, I am the only one who is writing program. Therefore, my need is very basic but I need something I can track back my version and code history instead of making a local copies of files for each version and tracking via Revision History (in VI Documentation).

[JÞB]

You could ask 12 developers and get 14 opinions.

For me, tsvn ( it's free) and the TSVN Toolkit by VIEWPoint systems ( its free) are more than enough and have a gentle learning curve with easy to understand documentation.

Anything is better than pressing Ctrl+Y!

[santo_13]

You will get all sorts of responses.

This will be my order of preference - Perforce > SVN > Git

But unfortunately, Git is increasingly adopted by LabVIEW developers due to peer pressure from text-based programmers and cost-cutting/DevOps integration initiatives in many companies.

---

[crossrulz]

I used Tortoise SVN for a long time.  More recently I was shoved into using Git Hub.  If going with Git, I used Source Tree as the interface.  It will do anything at a basic level you will need to manage your repository.

[Bob_Schor]

Been very happy using Tortoise SVN.  This works best (of course) when someone else (reliable) runs the Server ...

Bob Schor

[billko]

I liked SVN with the TSVN shell.  Then I got shoved towards GIT, where I use the Tortoise GIT interface, which they tried to keep the interface as close to TSVN as they could.

The SVN/LabVIEW combo already has issues with large repositories, but at least it only exists in once place.  With GIT, copies of the repo exists everywhere someone is using it.

[cbutcher]

---

@santo_13 wrote:

You will get all sorts of responses.

This will be my order of preference - Perforce > SVN > Git

But unfortunately, Git is increasingly adopted by LabVIEW developers due to peer pressure from text-based programmers and cost-cutting/DevOps integration initiatives in many companies.

---

---

I'm not sure my motivation was really related to peer pressure or text-based programming, but I agree that Git is increasingly adopted and recent moves by NI seem to be favouring Git. (I use Git with LabVIEW for all of my libraries/projects/whatever that deserves more than C:\Users\me\Desktop\junk as a home)

On the other hand, merge operations are a pita and with SVN as I understand it, you never have that issue... so that's a potential upside for SVN.

I like being able to commit and adjust things without needing a (or without a connection to the) server, and also being able to (if desired) just use another (e.g. network) folder as the "server" (`git init --bare` is what you're looking for here, in the target directory).

If you never try to merge or diff, it's very easy to use Git. If you only want to diff, it's not too bad and there are various versions of scripts around on the forums to help with setting that up (you need the Pro version to get LVDiff, so if you don't have that, no dice regardless).

If you want to merge, probably better to reconsider - typically I've found it easier to diff, potentially copy-paste parts into a new VI, close the diff and then pick the closer of the two branches for the merge, take that one and manually readd the changes using the new throwaway VI as the source for copy-pasting back...

[santo_13]

---

@cbutcher wrote:

---

@santo_13 wrote:

You will get all sorts of responses.

This will be my order of preference - Perforce > SVN > Git

But unfortunately, Git is increasingly adopted by LabVIEW developers due to peer pressure from text-based programmers and cost-cutting/DevOps integration initiatives in many companies.

---

---

I'm not sure my motivation was really related to peer pressure or text-based programming, but I agree that Git is increasingly adopted and recent moves by NI seem to be favouring Git. (I use Git with LabVIEW for all of my libraries/projects/whatever that deserves more than C:\Users\me\Desktop\junk as a home)

On the other hand, merge operations are a pita and with SVN as I understand it, you never have that issue... so that's a potential upside for SVN.

I like being able to commit and adjust things without needing a (or without a connection to the) server, and also being able to (if desired) just use another (e.g. network) folder as the "server" (`git init --bare` is what you're looking for here, in the target directory).

If you never try to merge or diff, it's very easy to use Git. If you only want to diff, it's not too bad and there are various versions of scripts around on the forums to help with setting that up (you need the Pro version to get LVDiff, so if you don't have that, no dice regardless).

If you want to merge, probably better to reconsider - typically I've found it easier to diff, potentially copy-paste parts into a new VI, close the diff and then pick the closer of the two branches for the merge, take that one and manually readd the changes using the new throwaway VI as the source for copy-pasting back...

---

I agree it should not be based on peer pressure, but in most cases, the decision is beyond you if the decision is org-wide.

I like SVN and Perforce better than Git and below are few reasons why I like,

1. Doesn't take much space on the disk as repo it is maintained on the server
2. You can download only certain sections of the repo and not just all files on repo
3. You can lock files so that none else uploads a version while you're working on it
4. Versions are managed file-wise, you can get older version per file not for the whole repo
5. You can merge versions per file and not a repo
6. You can create tags or snapshots (export bunch of source into a separate folder like release and still trace back the versions to the source where you branched off)
7. LV Compare/Merge options integrate well

[alexderjuengere]

we use git + gitlab

[crossrulz]

---

@cbutcher wrote:
...and recent moves by NI seem to be favouring Git.

---

NI recently went through a transition from Perforce to Git internally.  So that is one of the reasons NI would be favoring Git.

The other good reason is Git is the most used SCC tool out there now.  GitLab and GitHub are major contributors to this trend.  But even among the LabVIEW community, I find the "heavy hitters" are using Git and the rest are split between Git and SVN.   This is a general observation and not meant to be all inclusive.