Table Of Contents

Recommendations for Developing a Project Stored in a Source Code Control Repository

Version:
Last Modified: April 10, 2020

Because graphical code interacts differently with source code control systems than text-based code does, follow NI's recommendations for developing a project stored in a source code control (SCC) repository.

spd-note-note
Note  

The following information uses examples from Subversion (SVN) and Git. However, you can apply these concepts when interacting with any source code control system.

Recommendation Details
Create modular code within the project.

Modularity is a software design technique where units of code are collected together into logical and functional groups called modules.

Modularity reduces the likelihood that changes to one module of code will introduce unexpected changes to another module of code.

To build modularity into your project, create VIs and subVIs that handle specific, limited tasks. Use applications and libraries (.gcomp) when you want to group files together to perform a cohesive set of tasks.

In team-based development environments, modular code helps create logical divisions of work between developers.

Avoid making simultaneous changes in a VI.

The likelihood of broken code increases when multiple developers modify the same VI simultaneously. Merge conflicts are possible when developers submit conflicting changes in a VI.

If you use modular design techniques in the project, you can assign modules to individual developers on your team to reduce the likelihood that multiple developers will modify a VI simultaneously.

Some source code control systems allow you to lock files when you check them out. Use this feature to prevent others from modifying a VI while you have it checked out.

If you cannot avoid simultaneous development of VIs in a project, use NI Compare to view differences between two versions of a VI, then manually combine the differences between each version.

If you make changes to source files in the project, communicate with other developers on your team.

Modifications you make to source files in the project can produce changes to the project file as well as other files. Communicating with your team when you make changes helps other developers to quickly identify conflicts with their work.

Using a collaboration tool can help streamline communication on a development team.

Some collaboration tools, as well as some source code control systems, can auto-generate emails when changes to the repository occur.

Configure the project directory in the centralized repository to ignore submissions to the following project sub-folders:
  • Builds
  • .cache

Changes within these sub-directories do not affect the functionality of source code in the project.

In SVN, apply the svn:ignore property to the sub-directories.

In Git, list the sub-directories in the .gitignore file.

Perform code reviews before submitting code to the central repository.

Code reviews improve the quality of the code in your project and preserve the integrity of your source code as it changes during project development.

Consider implementing a tiered review framework on your development team. For example:
  • Peer reviews verify that the submission does not contain defects.
  • Owner reviews verify that the submission adheres to architectural guidelines.

As a code reviewer, you can use NI Compare to compare two versions of a project file or VI.

Create a Package Dependencies (.sls) document and keep it up to date during project development.

When you include a Package Dependencies (.sls) document in the project, developers can update this file as they create code, then other developers can use it to keep their development systems in sync.

For VIs, disable the auto-merge utility in your source code control system.

The underlying source of a VI file is XML-based text. When merging two versions of a VI, the auto-merge utility might combine lines of text from each version in a way that corrupts the VI and prevents the VI from opening.

If using the auto-merge utility on a VI breaks code, you may need to revert the VI to an older version to recover your code.

Minimize occurrences of renaming and moving files.

When you rename or move a file, SCC systems delete the file and create a new file with the new name or location you provide. This operation erases any version history of the file with its previous name or location. Other developers could introduce a breaking change when they submit files that use the old name.

You might encounter this behavior when you move a VI file to an application or library.


Recently Viewed Topics