My journey

from SVN to Git

Thanking to Fabiola De la Cueva and Emilien Kia for reviewing this presentation

Olivier Jourdan <>


  1. Why this journey ?

  2. My Travelog

  3. Today

  4. Advice

Part I

Why I started on this trip

Reminder about Version Control System

  • VCS records changes to a set of files over time

  • VCS allows reverting any file back to a previous state

  • VCS can tell when and who made changes to a file

  • VCS gives a way to collaborate with other developers

Important notes about Version Control System

You must use it, even if you are working alone!


This is not a backup system

Reminder about LabVIEW particularity

  • *.vi and *.ctl are binary files

Binary files can’t be merged, if a conflict happens, you need to choose between files.


  • *.lvproj, *.lvlib, *.lvclass are XML files

Auto-merging XML files can be dangerous

Why migrating from SVN to Git?

  • Objective motivation

    • features that not exist in SVN

    • Cloud service integration (GitLab, GitHub…​)

    • CI/CD tools

  • Subjective motivation

    • Curiosity

    • Trend of adoption in LabVIEW community

Which version control do you mostly use with LabVIEW?

spring 2020 - 83 participants

What do you plan to do?

spring 2020 - 83 participants

Was there any risks?

Read on the internet back in 2018…​

Git is awesome

Git is more complex than SVN

Git is not handling binary files correctly

Git needs to use command lines

Git forces you to merge

Part II

My travelog

Daily routines comparison








Staging area

Staging Area

Centralized versus Distributed

  • SVN and Git have a different architecture

  • The impacts can be substantial

Centralized architecture

Centralized VCS architecture

Distributed architecture

Distributed VCS architecture

Changing the routines



Stage → Commit (local) → Push (remote)


Centralized vs Distributed VCS architecture

Find out new features

  • Amend

  • Stash

Rebase / Squash / Cherry pick / Bissect

Working with branches

Git branching model makes it stand apart from SVN

  • Creating, merging, switching and deleting are simple and fast actions

  • That means you can:

    • Switch context easily

    • Define roles for branches

    • Create branches for experimentation and forget them

Find your own workflow

  • Git is an open system that can adapt to an infinite way to work

  • Define the team workflow is really important

Which version control do you mostly use with LabVIEW?

Spring 2020 - 83 participants



Feature branche

Feature Branch

Git Flow

Git Flow

Pull/Merge request

  • Kind of process above Git

  • Allow you to delegate the merging responsibility to someone else

Merge Request

Find the right tool

Command line


Tortoise Git





annual fee


One-time purchase


Free/annual fee

Not tested yet

Visualise commit history in Fork


Commit changes in Fork


Start a feature (Git Flow) in Fork


Part III



  • Moving to Git requires learning effort

  • Going out of your comfort zone makes you learn intersting things

Git vs SVN

  • Everything I was doing with SVN can be done with Git

  • We use Git for all project at Wovalab

Locking files is not possible with Git (at least, not easily…​)


  • We use Git Flow as our main branching workflow

  • Git is agile enought to fit the development context

  • Your Git workflow is going to improve/reinforce your development process

Access to many new things

Part IV

My advice for this journey

Understand the distributed architecture impacts

  • Commit (local) vs. Push (synchronization with a remote repository)

  • Modifying commits history already pushed can lead to headaches

Define your workflow

Make your git workflow best fit your development process and vice versa

Some ideas

  • Want to mimic SVN trunk → Centralized

  • You are building software that is explicitly versioned with Semantic Versioning → Git Flow

  • You are collaborating to open source project or have a strong code review process → Fork / Merge Request

Commit rules

Be kind to your future you.
LabVIEW Graphical Programming - 5th Edition (p.516)
— Fabiola De la Cueva
  • Often

  • Clear message (explain "what and why" instead of "how" )

  • Cohesive (only one reason i.e., adding feature or refactoring not both)

  • Mindful (only file you voluntarily modified)

To avoid getting more file changed than you have really modified use separate compiled code from files option

Repository content

  • Without config files

  • Without build artifact

Use .gitignore file to skip folders or files in your working copy from being versionned


Use a release server to keep your artifacts

Detach Head

You can lose data

Build a modular architecture

Whatever Version Control System you use, a modular architecture is essential to work as a team on the same project.

Talk, talk, talk

No Version Control System can replace communication within a development team.

Travel guides

Travel with a guide!

Any questions?

Thank you

gla mascot