Version control is essential for engineering development, verification, and support. This applies equally to electronics hardware, software, and firmware.
Having a robust way of managing changes prevents guesswork, minimises the effects of a “bad day”, and delivers a complete picture when the history is needed for an investigation.
All-in-all, this saves time searching for older versions of documents and lowers the chances of accidentally losing data.
The Three Different Types of Version Control
Local Version Control System
Local VCS is a single local file stored on a device and made accessible via snapshot imaging or patches. This allows users to roll back to a previous version of the file, but only at local level.
This is a significant single point of failure – if the device fails for whatever reason, the file is lost forever unless it has been backed up elsewhere.
Centralised Version Control System
Centralised VCS is where a centralised version of your project is stored on a server.
You are able to pull a local copy to your device, and then commit changes to the authoritative server-side version. However, if the server becomes inaccessible, no local user can access the project.
As with a local VCS, regular backup measures as part of your wider business continuity strategy are essential in order to manage the single point of failure risk. Otherwise, there is a risk of data loss.
Distributed Version Control System
A distributed version control system is a highly flexible VCS, with both speed and data security advantages over the other types of VCS.
Rather than the snapshot-based version control seen with local and centralised VCS’, distributed version control systems mirror the live document locally for all users, including a full file history.
The great thing about DVCS is that it eliminates the single point of failure risk associated with of previous versions control systems. Even if the server fails, or one of the users’ local files becomes corrupted, the file can simply failover to another active user who is mirroring the server version.
This means the user doesn’t need to rely on centralised data – or on a single technology.
Benefits of Using a Version Control System
Minimise risk of data loss
Each time you save a file state, a new version is created, removing the ‘all or nothing’ approach to file management.
This means that if you encounter an error, or need to rollback for any reason, you can select a specific snapshot and restore your data from there.
Ensure clarity of data
You could choose a low-tech approach of simply numbering versions by saving files as 0.1/0.2 or V1/V2 to differentiate your versions, but this can get very messy, very quickly. Plus, it doesn’t allow for easy comparisons between versions.
Therefore, it’s more beneficial to use a recognised version control system. This way, you’re able to store file states in a cleaner manner, making it far easier to determine whether your document is up-to-date, and reduce the risk of accidentally deleting a ‘version’ you’re working on.
Full development data trail
Whether you’re working on a particularly complex development project, or even a simpler one, having a straightforward data trail with easy access to the information you need is highly recommended.
Each time you commit to the repository, a new version is added to the database, chronicling each stage of development in a clear and concise manner.
Top Tips for Making the Most of Version Control
Implement branching logic
Some VCS allow tree-like structures to be setup. The main development path can be on one line with other branches veering off for trial features or developing new functionality.
This also allows each released version of code to be maintained so that critical bug-fixes can be made to an older code release without being forced to update to the latest and greatest code base.
Approaches like this can be helpful where a complex configuration needs just one key update which can be applied and tested without bringing in other potential issues.
Take advantage of collaborative working
Version control repositories also open the option for collaborative working between multiple developers in different locations on the same or different branches.
Different coders can work on different parts of a software development project before uploading or committing their well-tested and commented updates back to the repository for integration.
In multi-developer environments care needs to be taken that any new commits are not done at the end of the day. Commit and run should be strongly discouraged because buggy code can cause problems for other collaborating developers.
Don’t forget to make notes
Collaboration still requires efficient communication.
Therefore, each commit back to the repository can (and should) have notes associated with it. This makes the repo more user friendly and builds a history as it develops.
Formal releases of schematics, printed circuit boards, Gerber files, bills of materials, DLLs, libraries, binaries and source code can have the full release package secured in the repo to give certainty over what was in each release. This also allows the release to be reproduced if required.
Popular Version Control Systems
Git, Subversion and Mercurial are all version control systems each of which have their own architectures, foibles and methodologies.
Here’s a breakdown of what to expect from each system:
Apache Subversion
Subversion is an open-source centralised version control system, designed to store versioned files of source code, web pages, and documents – amongst other things.
https://subversion.apache.org/
Git
Git is one of the more popular open-source version control systems out there.
As a decentralised VCS, it allows users to perform operations on a local level, making it faster than centralised systems. It also features a local branching model.
Mercurial
Similar to Git, Mercurial is an open-source distributed version control system.
Whilst similar in functionality, Mercurial departs from Git’s C language by using Python primarily, with portable C used for the occasional performance-related reason.
https://www.mercurial-scm.org/
The pros and cons of each system depend on your own requirements, file types, and ways of working. If you’re unsure which system would work best for your organisation, then let’s talk about your project.
Conclusion
Whether you opt for a local, centralised, or distributed, using a version control system is always recommended over manually saving separate files.
Your data will be cleaner and therefore easier to find – plus you’re less likely to suffer data loss by accidentally deleting manually ‘versioned’ files.
It’s a simple solution to a potentially challenging problem.
Blog Authorship
This article was written using research by John McCrea, Marketing Executive, along with the knowledge of Richard Fletcher, Ignys MD who has worked in electronics design & software development for over 20 years.