- Overview
- Library Service Options
- Library Footprint Creation
- Library Footprint Validation
- Library Footprint 3D Models
- Library Sustainment
- Quote Request
- Library Introduction
- What's Your Structure?
- Why Conformity Matters
- Who's Your Librarian?
- Library Clean Up
- Symbol Style Guide
- DFM Library Example
- Library Resource Videos (18)
- Avoiding Gotchas
- Altium Vault Offerings
- Configuration Setup
- Vault Management Videos (16)
- Overview
- Point of Entry
- L9 Videos (4)
- L9 vs. Vault
- Evaluation
Should You Pursue an SVN (or GIT) Version-Controlled Library?
Several years ago, when we first published this commentary, our scope of "version-controlled libraries" was limited to the SVN Database Library (SVNDBlib) offered within Altium Designer. This specific library architecture consists of:
- An external database: A product like SQL or Microsoft Access that maintains the component parametric information
- A revision controlled repository: A centralized company server that manages the versioning of the individual symbol and footprint schematic/PCB library files.
Through our experience, we found this specific methodology to be cumbersome, often providing little benefit relative to the effort required to maintain it.
As for Git, Altium has not created a mechanism that integrates directly into a company's Git repository. Although Altium does use Git to assist in the project maintenance in its A365/Enterprise offerings, even then it does not use it for components or templates. If Git was to be used, its management would be done outside of Altium Designer.
Note that the rest of this commentary is applicable to both SVN and Git.
The Complexity of Revision Controlled Libraries
Setting up and maintaining a database library is already a significant undertaking, requiring a deep understanding of both database structures and library management. Adding a version control system like SVN introduces another layer of complexity.
It is important to distinguish this from Altium 365 (Standard, Pro, and Enterprise). Altium 365 is a version-controlled file management system by design; versioning is an integral part of the software and cannot be "turned off."
Why We Question the Need for Component-Level Versioning
We believe that a revision controlled database library is often unnecessary. We typically only see a genuine need for such systems when they are mandated by an end customer or specific industry standards.
Even the medical electronics industry, which is heavily scrutinized by the FDA, does not strictly require version-controlled libraries; rather, they demand that the project itself is tightly controlled. Any subsequent changes to a project require a rigorous review and, in many cases, new clinical trials.
To be clear: library files should be kept in a document version control system for safekeeping and backups. However, we question the necessity of version control for each individual component.
Points to Consider
- No Impact on Creation Speed: Version control does not streamline the library creation process; it simply adds another administrative task. The actual process of building a component remains the same.
- Propagation and Review Hurdles: When using a version-controlled library, updates must be propagated to active projects. Updates to a symbol or footprint graphic will necessitate a full review of project drawings to ensure no wiring was inadvertently disconnected or misconnected.
- Version Control ≠ Lifecycle Management: Version control is merely time-stamping and tagging a file with a sequential identifier. Lifecycle management refers to the status of a file regarding its stage of usefulness (e.g., New, Prototype, Production, Obsolete, etc.). When a version-controlled file is edited, a new file version is created, but the "approved" lifecycle status does not automatically carry over. The new version must undergo the same review and lifecycle approval as its predecessor.
- Repository Bloat: Version control prevents files from being overwritten. If a file is modified, the system saves it as a new version while retaining the old one. Without a strict library style guide, frequent minor changes can quickly bloat the repository with unusable versions. In a revision controlled database library, where every component is its own file, this can become unruly.
The "Point of Entry" Issue
In summary, version control is not a magic bullet for managing the flow of components from designers into a central library. At Nine Dot Connects, we call this the "point of entry" issue.
Components often start their life with incomplete or incorrect information, or they fail to meet company formatting standards. The longer an erroneous component progresses through a project, the harder it becomes to correct it across the entire design ecosystem. Adding version control to a flawed entry process only manages the history of those flaws - it doesn't fix them.
What is your experience? If you hold a different opinion or have successfully implemented a version-controlled database library, we want to hear from you. Please contact us to share your "hows" and "whys."
