Code control systems for LabView

[Flonares]

Hello, 

I´ve been searching on the forum for a robust way of doing code control using, for example, Github or Gitlab. For reference, https://forums.ni.com/t5/Reference-Design-Content/Getting-Started-Git-and-GitHub-setup/ta-p/3544824

I am extremely curious to know how you manage your code. Can you provide suggestions on how to create a repository so that I can keep different working versions of my projects?

(This should actually have been my first question before starting my project. However, I used a dumb-but-simple approach that I wish now to reform...)

Cheers,

Fl0

[santo_13 · Accepted solution]

Related content,

https://education.ni.com/center-of-excellence/resources/450/session-getting-started-with-github-and-...

Before we get into source code control for LabVIEW, there are several YouTube videos on basics of source code control using Git, once you're familiar with the concepts, that can be scaled to LabVIEW with few differences.

[billko]

I think SVN has a slight advantage over GIT for LabVIEW because you don't need to replicate the repository.  Because all LV files are treated as binary, the repo can get big in a hurry.

[BertMcMahan]

Here's a good article from Delacor on the issue:

https://delacor.com/every-developer-needs-a-time-machine/

[santo_13]

---

@billko wrote:

I think SVN has a slight advantage over GIT for LabVIEW because you don't need to replicate the repository.  Because all LV files are treated as binary, the repo can get big in a hurry.

---

In my experience, both SVN and Perforce have a good edge over Git since they track versions per file, allow single-user edits through locking, and centralize revisions.

[TiTou]

---

@santo_13  a écrit :

---

---

In my experience, both SVN and Perforce have a good edge over Git since they track versions per file, allow single-user edits through locking, and centralize revisions.

---

That's interesting, you see "centralized" as a plus?

I used SVN a long time ago, when I discovered decentralized VCS I quickly abandoned SVN.

I started with Mercurial and then went to Git.
I don't think I could work with centralized again, having multiple clones of the repo is such a useful concept.

Oh and I suggest reading this : https://www.joelonsoftware.com/2010/03/17/distributed-version-control-is-here-to-stay-baby/

[santo_13]

---

@TiTou wrote:

---

@santo_13  a écrit :

---

---

In my experience, both SVN and Perforce have a good edge over Git since they track versions per file, allow single-user edits through locking, and centralize revisions.

---

That's interesting, you see "centralized" as a plus?

I used SVN a long time ago, when I discovered decentralized VCS I quickly abandoned SVN.

I started with Mercurial and then went to Git.
I don't think I could work with centralized again, having multiple clones of the repo is such a useful concept.

Oh and I suggest reading this : https://www.joelonsoftware.com/2010/03/17/distributed-version-control-is-here-to-stay-baby/

---

I had my fair share working with SVN, Perforce and Git. For LabVIEW, SVN or Perforce workflows are better and especially for a newbie to source code control before getting into Git workflows as the paradigm changes and need a better software engineering mindset to effectively use Git.