Should I pursue an SVN (or GIT) version-controlled          library?

Several years ago, when we put forth this commentary, our scope of a version-controlled library was limited to the SVN database library offered within Altium Designer. This style of the library consists of:

• An external database product like SQL or Microsoft Access maintains the component information.
  

• An SVN repository that resides on a company-shared server for the versioning of symbols and footprint graphics.
  

We found through our experiences that this library method was very cumbersome and seemed to provide little benefit for the effort.

Setting up and maintaining a database library is already challenging. It requires an understanding of both database structure and library component management. Adding the additional element of setting up and maintaining a version control system like SVN adds a layer of complexity.

Altium Inc. recently offered three versions of Altium 365 file management products like Standard, Pro, and Enterprise. These are version-controlled based file management systems. These cannot be turned off since they are an integral part of the software. Such systems have implications for the deleting and editing of any file.

The commentary below is specific to the SVN database offering in Altium Designer. However, some of these concerns apply to ANY version-controlled-based products.

-------------

We believe that an SVN database library is unnecessary. We see a need for such libraries when it is being mandated upon the company by an end customer or an industry standard. Even the medical electronics industry, heavily scrutinized by the FDA, does not require version control libraries; they demand that the project is tightly controlled. (Any subsequent changes to the project require review and, very likely, new clinical trials.)

This is NOT to say that library files should not be kept in a document version control system for safekeeping. However, we question the need for version control for each component.

Here are some points to consider:

• Version control will not streamline the library creation process. It only adds another task to the effort. The process of building a component remains the same.
  

• When using a version-controlled library, updates to the library will need to propagate changes to the projects. The user must do this periodically. Note the updates to the symbol or footprint may result in updates to the graphics in the project, requiring a review of the drawings to ensure that no wiring was disconnected or wired inadvertently.
  

• Version control is not life cycle management. Version control is time-stamping and tagging a file with a sequential number or letter. The life cycle is the status of a file in terms of its stage of usefulness. A new file is created when a change is made to a version-controlled file. However, the life cycle does not propagate to the new file. Since there is a change to the file, it requires review, and thus the new file must go through the life cycle process that the prior file from which it came was subjected to.
  

• Version control does not allow an existing file to be written over. If a file needs to be modified, a copy of the latest version will be available for editing. When saving the file, it will be stored under a new version. The old file is not deleted. If a library-style guide was not established initially, constant changes would be made, thus bloating the repository with useless files. Remember that each component has its own file in an SVN database library.
  

In summary, version control will not streamline a way of managing components flowing from the designers into a central library. This is what we at Nine Dot Connects call a "point of entry" issue. All too often, components start incomplete, have missing or incorrect information, or are not formatted optimally to maintain the company's overall look and feel of the library. The longer this component progresses through the project with errors or omissions, the harder it is to correct it throughout the entire project (or projects).

If you differ in opinion or have successfully implemented a version control database library, please contact us. We would like to know the hows and whys.

See L9 Overview

Request Evaluation