Why Do I Need Version Control?

Reason #1: Danger

There are a lot of compelling reasons to use version control systems. Probably the most important reason is to mitigate the danger of losing your work. I frequently come across engineers who are completely unfamiliar with version control systems. Every time this happens, this is what I see:

OK, so these engineers aren't actually risking their lives when they don't use version control. But they are definitely working without a safety net. The question is...why?

I am always baffled by this situation. Why would anybody choose to take the unnecessary risk of losing any of their work to a disk crash, careless changes, accidental file deletion or other mishap when these issues are so easy to avoid.

As I'll cover shortly, modern version control systems are ubiquitous, easy to use and free. What possible barrier could there be to using one?

Reason #2: History

The risk of losing your work is probably the strongest argument I can make to an engineer about the value of version control. But another argument for version control is the fact that it gives you a way to manage all your files while maintaining a complete history.

I cannot tell you how many times I've seen a directory full of files with names like:

• CalcProperties.f77.bak
• ThesisModel.py.working
• Circuit_jan23.mo
• model.c.fred

This is, frankly, insanity. Most people who manage files this way would probably argue that their system "works for them", that they don't want to learn some "complicated system" or that version control is "overkill" for them. I, however, would argue that a version control system is easier to use than such ad hocs approaches and provides far, far, greater capabilities and features. The key point here is that when trying to get people to adopt any technology, there has to be a good return on investment. They need to get out of it more than they put into it. I would argue that for all modern version control system, you will get this return on investment even if you don't use all the fancy features.

I've heard engineers argue that they don't need a version control system because when they need to, they can create a zip/tar file and stash that away some where. They'll even argue that's pretty much what a version control system does. If you think this is true, you should read the excellent book Pro Git (free online version) so you can appreciate how version control systems really work.

Reason #3: Collaboration

The final reason for using version control (that I'll talk about, at least) is collaboration. I think of this reason as "icing on the cake" because a) it isn't really a strong enough argument by itself and b) for reasons I'll talk about later, it doesn't always apply to engineers.

I clearly remember once talking with a colleague of mine who worked in a modeling group. I was trying to explain to him the advantages of the configuration management features in Modelica to promote collaboration. He kept insisting he didn't need that. So I asked him "How do you collaborate with the other people in your group?". He then explained that they had a shared drive and they all just worked in that one directory. I asked him "But how do you manage the different configurations of the models?". He explained that they just saved each configuration with a different file name. To give you a sense of how sophisticated their taxonomical approach was, one of the files was called "TheBigKahuna".

If I found myself in such an environment, I would start pinching myself in the hope that I'd suddenly wake up, drenched in sweat with the comfort of knowing it was all just a nightmare.

Modern version control systems provide an outstanding platform for collaboration. They allow each developer to work independently when needed. But, they also allow people to collaborate by seamlessly and effortless pulling and pushing changes to each other.

But the possibilities for collaboration transcend the version control systems themselves. Various tools and applications layer features like documentation, issue tracking and other collaboration facilities on top of version control systems to create extremely rich and user friendly collaboration platforms.

How to Get Started

There are a variety of version control tools out there. Most engineers don't want a survey of tools, they just want to know what they should use and how to get started.

I would argue that the most user friendly version control system for engineers would probably be Subversion (SVN). For those engineers working on a Windows desktop, I would strongly recommend the TortoiseSVN software.

I can already hear the cries of those "in the know" screaming "Don't tell them that, Subversion is ancient history, Git is much better!"

You will note I said that Subversion was more user friendly and I stand by that statement. But it is true that SVN is increasingly falling out of fashion and, simultaneously, user interfaces for Git are improving. YMMV.

It isn't simply SVN itself that is losing mindshare, but the entire approach that SVN takes. You see, Subversion is an example of a centralized version control system. Each project has a single, central server that acts as the "database" for the entire history of branches, tags, commits, etc. This centralized approach is increasingly being phased out in favor of "Distributed Version Control Systems" (DVCSs). Among these DVCSs, the most widely used system is Git. And, as is the case for most version control systems, Windows users can use a nice graphical front end in the Testudinidae family called TortoiseGit. It is also worth mentioning another popular DVCS called, Mercurial, which is similar to Git in exactly the same way that Lilliput and Blefuscu are similar.

Personally, I have used Subversion, Mercurial and Git extensively but I currently use Git exclusively. Although the differences between Git and Mercurial are minor, it seems clear that Git is and will remain the dominant player in the DVCS space. One of Git's big advantages is that it is supported by collaborative platforms like GitHub, BitBucket and Trac. These tools can greatly enhance the capabilities of the underlying version control system.

GitHub is the darling of the open source world and it seems the vast majority of projects are hosted there (including several of Xogeny's). GitHub also features "private repositories" for non-open source projects. But if, for whatever reason, you are not able to use GitHub, I'd strongly recommend Trac since it can be self-hosted (e.g. behind a firewall).

The Good, The Bad and The Ugly

The Good

The tools I mentioned above are free. They are also well engineered tools that have been well hardened by use. They are all extremely reliable. These tools are also well documented with lots of books and online resources that you can reference.

The Bad

Actually, there is no bad. There is only good and ugly...

The Ugly

I mentioned that SVN is the most user friendly. This was not so much a comment on SVN as it was on Git. Git's command line interface is, to be generous, "confusing". Fortunately, you don't need to worry about this too much if you use a reasonable UI like TortoiseGit and you eventually get used to it (for better or worse). Ample documentation on Git helps here too.

But there is some additional ugliness to be aware of lurking out there. This is because, as alluded to earlier, you may have trouble using version control tools for engineering because your engineering tools make this unnecessarily difficult. I wrote about this in one of my earliest blog posts, "A Disturbing Trend". Those complications really only affect the collaboration part. You can still use version control tools to keep a complete history without issue.

Frankly, as engineers we should be pushing back on tool vendors who insist on breaking from traditional line oriented formats for engineering content to invent their own unnecessarily opaque formats that are incompatible with accepted practices in the software engineering world.

Conclusion

I recently gave a talk at "The Ohio State University" (they are very fussy about the "The"). The talk I was giving lamented the fact that engineering was pretty much the entire impetus for the development of both computer hardware and software but today engineering is so out of touch with modern concepts of computing. In this particular lecture, my host asked the audience (composed largely of people who build mathematical models) how many people had heard of Modelica. He was trying to underscore this point about engineering being out of touch with the latest computing trends. As much as I like Modelica and as much as I would agree that ignorance of Modelica is indicative of this trend in some small way, I interrupted to add "You are asking the wrong question...how many of you use version control?", I asked. Predictably, hardly anybody raised their hands.

While predictable, this response was still disappointing. As an engineer, you have many reasons to use version control and no reason to avoid it. Engineers often look at version control as a technology exclusively for software developers. But engineers routinely develop "software", they just don't realize it.

I'm afraid this post doesn't live up to my goal of providing some kind of all inclusive introduction for engineers to the world of version control. I've at least provided some pointers and some advice. Frankly, there are so many resources out there that it really isn't worth repeating them. I'll be happy to answer any questions or concerns in the comments though.