I gave a presentation during NI LabVIEW Developer Days at Austin, TX. I prepared this presentation for Dev Days and it was presented at other locations in the world, too.

Below is a video of the presentation given at Austin, TX. If you want to see the demonstration videos only, they are found via the bitly.com/LVscc playlist (it also includes the videos from the Every Developer Needs a Time Machine post).

I know this cartoon is getting old, but there were still two people in the presentation that said: “I don’t use source code control, because I am a single Developer”… so, maybe the world needs to see it again 😉

Seriously, good programming practices have nothing to do with marital status! If you are not using SCC, you are playing with fire!

While preparing this presentation, I realized that in the LabVIEW Community, we tend to call it Source Code Control. However, the rest of the world calls it Version Control Systems (VCS), Source Code Management (SCM) or RCS (Revision Control System). I think it is important to share these new terms to help you in your search for more information.

One thing I have learned while working with different teams is that every project, regardless of size, benefits from Source Code Control. A good way to figure out if you should use source code control or not is to think about how many hours of your day you are willing to lose if your project gets corrupted. Make this your trigger to decide whether or not to use Source Code Control.

One more thing, SCC commits without comments are like a movie script without the main plot. It is not just having a track of revisions and what changed, commits are also a good way of sharing the developer’s state of mind and share intent. They are an investment on your Technical Wealth. Recently, one of our customers mentioned that a feature had disappeared along the way. We were able to figure out that the VI was modified several times, specifically, there was a commit from October, 2015 that said the customer had requested for us to remove the feature and pointed to a case in JIRA. The JIRA case had the customer’s reasoning to request the change. It is OK for our customer to change his mind, but we were able to share what his reasoning was back then. He requested to reimplement the feature, and the code from October 2015 was there for us to see and reimplement. We did not have to reinvent the wheel. In addition to the commits and the JIRA case, the developer who removed the feature had left bookmarks in the code and Unit Tests to verify that the feature would work well it it was ever reimplemented.

What is Source Code Control?

I don’t think I exaggerate when I say that the most important technical asset for any software development team is their source code control tool. It keeps track of every modification done to the code. Developers can “travel back in time” to see what the code looked like in the past, and revert changes or determine when a bug was introduced

No more:

We have seen these names. No customer was hurt while we gathered these names!

Centralized Source Code Control

A central copy of the project is in a repository (typically a server). Developers “commit” their changes to that central location. Examples: CVS, SVN, Perforce

Step 1: Checkout Working Copy

Step 2: Developer makes changes and commits

Step 3: Other developers get the change by updating their copies

Step 4: If two developers make a change, whoever gets second needs to update first and resolve any conflicts

Centralized Source Code Control: Disadvantages

  • Developer requires a connection to the repository in order to commit, update or read the log.
  • When committing, they need to address conflicts right then and there.
  • Developers do not commit as often in fear of conflicts or breaking others’ code.
  • Repositories tend to get too large, because developers can only checkout the section they are working on.
  • Having the entire code base in a single repository means that if something happens to the repository, the entire code base is affected
  • Leaves risk of developers calling source code in different parts of the repository as opposed to built/released code
  • Managing the history of a project is difficult, because it is combined with the history of other projects

Distributed Source Code Control

A central copy of the project is in a repository (typically a server). Each developer has a clone of the entire repository. Developers “commit” their changes to a local repository and “push” their changes to central location. Examples: Git, Hg (Mercurial)

Step 1: Clone Repository

Step 2: Developer makes changes and commits as many times needed to local repository

Step 2a: When ready, push commits

Step 3: Other developers get the change by pulling the changes into their local repository

Step 3a: When ready, update

Step 4: If two developers make a change, whoever gets second, pulls and can chose to update, resolve any conflicts and push when convenient

Branch Merge vs Code Merge

Branch merge: When the files of a project have been modified in two separate branches and get combined into a single branch. Different developers can work on different branches. This may or may not involve merging code.

Code merge: When the same code file has been modified in two separate locations and get combined into one final version of the code.

The video above shows all the steps for distributed source code control described before:

  • 00:00 Cloning on both computers
  • 00:24 Fabiola creates a new project and commits it
  • 00:48 Fabiola pushes changes
  • 01:02 Jane Pulls changes
  • 01:16 Jane Updates to the different commits Fabiola did
  • 01:39 Jane adds new library. This is going to be used to show how to handle the project. In this particular example, Jane decides to not commit the project and instead asks Fabiola to add it via the commit notes.
  • An alternative (not shown in the video) is for Jane to push the project changes and then let Fabiola resolve. In that case, Fabiola could update to see what Jane had done to the project and then decide if she takes the local copy or Jane’s copy. A third alternative is to merge the project file as a text file, however, this can result in a corrupt project.
  • 02:05 Fabiola pulls and updates Jane’s changes
  • 02:35 Fabiola adds the missing files to the project
  • Starting at minute 3:00 the video describes an ongoing project, where both Fabiola and Jane are making changes to the code. Never to the same file.
  • Jane has pending changes. She has committed but she has not pushed her changes yet.
  • She updates to the different versions Fabiola pushed, taking a peek to see that Fabiola changed the button text on one commit and added the Hello World code on the next.
  • 03:52 Jane is done taking a peek and goes back to her own version, where she makes more changes, commits and then when she is ready, she merges the changes with Fabiola’s changes.
  • There are no conflicts to resolve, because they were working on different files the whole time. This is an example of a branch merge.

LabVIEW Compare

LVCompare.exe is equivalent to “Compare VIs dialog box” found in Tools>>Compare>>Compare VIs. It is available only in the LabVIEW Professional Development System. Works like those “Find the differences” games we did as kids:

Remember it is “Find the differences” not “Where’s Waldo?”

Code image taken from the Rube-Goldberg-Code post in the NI forums.

LabVIEW Merge

LVMerge.exe is equivalent to “Merge VIs dialog box” found in Tools>>Merge>>Merge VIs. It is available only in the LabVIEW Professional Development System.

Just like LabVIEW Compare, it works better with small changes on small block diagrams.

Process and Architecture Smells

Throughout the years, I have encountered that the insistence on having LVCompare and LVMerge configured in the source code control tools is a process/architecture smell. It should be very rare that a developer needs to use either tool. Really the only valid frequent use for LabVIEW Compare is, in a regulatory environment, the Q&A person requests to see a redline comparison of what changed. 

Architectures where the VIs are coupled and not cohesive lend themselves more to developers needing to work on the same VI as another developer for implementing different features.

Library files: .lvlib, .lvclass, .lvproj are XML files, so you would think they are text files, except when they are no longer text files!. These files do include some binary information. Regular text compare tools can be used to identify some changes, but merge tools should be avoided, they can corrupt the files. 

At Delacor, we assign an owner for the library files. If two developers are working on the same library (but in different VIs) and they need to make a change to the library, they request the owner to make the change or check with the owner if it is OK for them to make the change.

Configure LabVIEW Compare

Find details on how to configure source code control with LabVIEW Compare in LabVIEW Help

While the information is there on the help, there are some caveats to consider when configuring third-party source code control tools.

LabVIEW Compare requires some LabVIEW wrapping to make it work with Mercurial. To find the tool, go to the Mercurial user group at NI ForumsAndreas S, System Engineer at NI created a tool that wraps LVCompare so it can be called from Mercurial. James McNally made some changes and both tools are available via Bitbucket.

Also, our friends at Endigit published a blog post on how to configure SourceTree to use LabVIEW Compare.

The video above describes how to configure TortoiseGit to use LabVIEW Compare as its Diff tool and the LabVIEW Merge to resolve conflicts.

At minute 1:00, the video shows how to configure TortoiseGit to use LVMerge to edit conflicts.

The video above shows a simple change in code. In this case just changing the Boolean text on a button, then using TortoiseGit>>Diff to launch LabVIEW Compare and compare the changes.

 

Configure LabVIEW Merge

Find details on how to configure source code control with LabVIEW Merge in LabVIEW Help.

The video above shows a simple change in code. In this case just changing the Boolean text on a button, then using TortoiseGit>>Diff to launch LabVIEW Compare and compare the changes.

The video above shows how to configure Mercurial to use LabVIEW Merge.

The video above shows the same thing that was shown in the Git video, but using Hg instead. This video shows the concept of a feature branch. The code will be changed both in the “master” branch and in the “feature1” branch.  Since the same file has been modified in both branches, there will be a conflict. We configured TortoiseGit earlier on to use LVMerge.exe for conflicts.

At minute 2:31, a conflict is detected and the video shows how to launch LabVIEW Merge to compare the changes and decide which ones stay and which one are not part of the merged VI.

Conclusion

Distributed Source Code Control does not require a connection to the central repository all the time

Every team member has a complete copy of the repository including the entire metadata

It is still advisable to have backups of the repository, but they are not as crucial as with Centralized Source Code Control

Avoid working on the same VI on different branches

Overuse of LabVIEW Compare and LabVIEW Merge is a symptom of an architecture that is not modular enough and/or a process that has multiple developers working on the same code at the same time

References

Special thanks to Matthias Baudot from StudioBods for helping me with some of the videos on this post.