Are there still embedded developers not managing their source code in a version control system?

Posted by Magnus Unemyr on Apr 28, 2015 2:18:10 PM

Unfortunately, yes. And it surprises me all the time that some developers still do not use this invaluable tool, since version control systems provide such enormous benefits and most of them are free as well. Nevertheless, I hear too often about embedded projects still not managing their code professionally by using a version control system.

One developer I spoke to was part of a 3-continent team, who worked on the same source code files by passing them around by email as the office hours shifted from continent to continent overnight. While this is an exceptional and extreme case that I never hoped to hear existed in the year of 2015, it is my opinion that even every single-developer project should use a version control system too. For multi-developer teams it should be mandatory, and any development manager not enforcing it really ought to think once again. This is why.

William Shakespeare once wrote: “many a truth is spoken in jest.”  Over the years practitioners of software development have made many serious and whimsical observations on the process. Two particularly relevant quotes to this discussion are:

“Any code of your own that you haven't looked at for six or more months might as well have been written by someone else” - Eagleson's law


“You can’t have great software without a great team, and most software teams behave like dysfunctional families” - Jim McCarthy

These maxims illustrate two essential points that make the use of version control a necessity instead of a luxury in real software projects.

The first point goes to the fact that sooner or later, developers must go back to old code for maintenance, bug fixing or feature enhancement. The difficulty inherent in understanding legacy code is familiar to anyone who has gone through the process. Documentation in the form of comments, state chart diagrams, graphics etc. may or may not exist, or be adequate to make the picture clear. Revision control history that tells who made changes, when they made them, and why they were made, is invaluable in gaining the vital insight necessary to effect modifications to an existing code base in a timely fashion.

Jim McCarthy’s comment reflects the sad but often true fact that communication among members of a development team may not always be the best. Using version control is a way to naturally enforce good communication and discipline among team members. When team members use version control, they are communicating with one another every time they perform fundamental operations such as checking in/out, merging, committing and tagging code, creating branches etc. These practices not only help individual team members orient themselves within the landscape of a complex project, they leave behind an irrefutable trail of history and documentation that can be mined for information at any subsequent time.

As the development progresses over time, it is typical for thousands of code changes to be made. If version control methodology is not used, it very quickly becomes unclear who made what changes, when and why. A bug fix may inadvertently introduce new bugs. As time goes on, valuable information about what the original code base looked like can be lost forever, making it impossible to revert to a previous code state of known working behavior. In this scenario, teams lose time, unnecessarily duplicate effort, and possibly work at cross purposes. Version control methodology is the key to bringing order to a potentially chaotic situation.


Further complicating the issue is that today’s development teams often consist of many developers spread out over different buildings, cites, countries or even continents. Communication may be hindered by time zone differences or business trips that inhibit asking simple questions like “is this bug fixed yet,” or “have these changes been made.” Version control is good news to such teams, because of they make it easier to obtain this kind of information even when colleagues are unavailable for comment.

Single developer situations are also excellent candidates for using version control. Besides Eagleson’s Law, the single developer frequently is a jack-of-all-trades whose responsibilities may include not only software development, but hardware design, parts specification and ordering, purchasing etc. In a small company, the same individual may also be doing the marketing, sales and the financial books. Time is at a premium! Version control methodology helps developers return their focus to a project after the inevitable interruptions. This pays dividends in the long run, preventing procedural errors like forgetting to fix important bugs or unnecessary re-engineering of old code.


Luckily, most developers already use version control systems, while some haven’t started yet. Arguments against adopting version control methodology frequently involve questioning whether there will be payback on the investment of time to learn such tools. Others contend that less rigorous methods such as regular backups, and/or tracking revisions on spreadsheets are just as effective. Single developers often argue that since they are the only authors and modifiers of the code that version control is unnecessary, because they have it “all in their head.”

All of these arguments are of very questionable merit. Most professional software development organizations insist on version control methodology supported by tools specifically designed for that purpose as a matter of policy. Using version control methodology is also considered as good software development practice and is usually a required protocol of development for mission critical software such as industrial control, avionics or medical devices. In the past, there have been examples of companies which have faced legal liabilities from their lack of implementation of version control when product defects occurred. These facts are persuasive evidence of the positive cost/benefit ratio of employing a sound version control methodology.

So what does this mean, more practically? Let’s take the free-of-charge Subversion (SVN) version control system as an example, as this is probably the most common version control system in current use with embedded developers today (although GIT is getting increasingly popular):

#1 - Subversion manages files and folders, and their changes over time. Subversion provides quantitative traceability of all changes in all files, throughout the complete lifetime of the project. As such, Subversion (or any other version control system) is a time machine that lets you move forward or backward in time (at least when it comes to your source code).

#2 - Subversion tracks changes not only in files, but in folders as well. Furthermore, version control methodology is not limited to ASCII-text files such as source code and header files. Any file including binary files like images, audio or even office documents can be put under version control. This is especially important as many of these kinds of files are important to the structure of the application, as well as forming the backbone of application specification and documentation.

#3 - Subversion allows you to retrieve older versions of your files for reuse, or to examine the changes made between any two versions of the same file. Subversion traces all changes made to a file, and so you can see how a file changed over time. It is also possible to see who made a change, when and why. If a code change introduced a problem, just revert to the previous stable version to undo the change and continue from there. In essence, version control systems are time machines that let you move backward and forward in time, and see what files and folders looked like at certain times during the project lifecycle.

#4 - The Subversion database server is best used by accessing it over a network using a client/server model. This has important advantages. It allows developers on the team to keep all relevant files in a central location that is accessible to everyone. The developers can work on the same source code files simultaneously. More than one developer can make changes to the same file at the same time, and the changes can be subsequently merged. In the rare event that the same line has been modified by two or more developers at the same time, a conflict manager detects the conflict and provides tools to resolve the conflicting code changes.

#5 - All the versioned files are stored in a centralized place called the repository. The Subversion repository can be accessed from client computers anywhere on the network. Many developers can work on the same source code files from various geographical locations, as long as the Subversion server repository can be accessed using a LAN or VPN connection. Consequently, it doesn’t matter if a development team is in the same place or spread out over various cities, countries or continents. All developers can have equal access the shared Subversion repository regardless of physical location.

#6 – Developers “check out” the latest (or any older) version of the source code from the server repository to a local working copy, where they can make any changes locally without interfering with the mainline source code tree or other developers. Once their changes are made they can be “commited” back to the server repository for everyone else to see and use.

#7 – Branches (copies) of the source code tree can be made for development tasks that should not be allowed to interfere with the main line of development. Examples here are release branches (where older product versions can be maintained with bug fix patches without affecting new development), or feature branches (where major new functionalities can be developed in isolation until they are ready to be integrated with the main line of development). If any branch of parallel development is to be integrated back into the main line of development, the branch is “merged” back with the main line of development.

#8 – Certain source code versions (snapshots) can be “tagged” with a name for easy reference later on; such as “v1.0”, “v1.1”, “Beta release to customer X”, etc. This makes it easier to find particular older versions of the source code.

#9 Great IDE GUI clients exist, allowing convenient access to basic operations like check-out/commit, branching and merging, tagging etc. But these GUI clients typically goes a lot further, allowing graphical file difference utilities to allow for visual inspection of differences of two versions of the same file for example, graphical visualization of WHO added WHAT code line WHEN, and for WHICH purpose. Advanced tools can even visualize branching and merging graphically, in a kind of flowchart graph.


It is my opinion that any embedded development, even in single developer projects, should use a version control system like Subversion (SVN) or GIT. Since these tools are open-source and free-of-charge, there really is no excuse to avoid managing your code in a professional way.

Good embedded IDE’s have integrated GUI clients for version control systems like Subversion or GIT, including Atollic TrueSTUDIO for ARM Cortex.

If you want to read more on version control systems in general, and using Subversion (SVN) in particular, read this extensive whitepaper:

 Read our Manage code with SVN whitepaper!

If you are interested in embedded development on ARM Cortex processors, read this whitepaper:

Read our ARM development whitepaper!


Topics: Atollic TrueSTUDIO, Embedded Software Development