Software Version Control

Backing up files is basically the process of moving them to a location where they are (at least some level) protected against accidental loss and as pretty much everybody in the 21st century works with files it's quite an important process. Smartphones and modern desktop operating systems do a pretty good job in automating this and get the burden off of the user's shoulder.

One simple example is how smartphones back up your contact list. Nowadays almost nobody stores phone numbers, email addresses of their contacts only on their cellphone but uses for example Google to take care of that. Google stores all this info on its servers (good or bad, it's another discussion) so if you lose or damage your cellphone your contact list is still intact on the server and once you have your new phone an application syncs it back to your phone.

Ok, but what about the files you work on a daily basis, for example excel sheets, word documents on your PC?

Actually there is a very good chance that these files are not backed up at all. Just to prove this I assume we all know that’Oh snap!’ moment when we accidentally deleted an important document and it cannot be recovered. Sometimes we just have to recreate it from scratch, but there are cases when the loss of the file could have very serious consequences: if one deletes business critical data then recreating the file might not even be possible, and even if it is it or it could be a serious effort. Losing important data for sure would cost money but also could have other consequences (eg: losing customer’s trust, lawsuits etc).

If we’d like to minimize the risk of data loss, backing up our files is critical.

In my past 30 years of dealing with both people and computers here are three common categories of how people usually do backups:

1. • The first type doesn’t create backups at all. There are people who really don’t need backups, and for them backup is just a burden. What I have found, though, is that a fairly high percentage of the non-backing up people actually should do backups, they are just either lazy or they don't know how they should do that.
2. • The second type is who makes local backups. Huge improvement over the first. These people (somewhat) regularly copy their files to somewhere on their local hard drive. If they tend to work with multiple files, then they usually copy all of them at once and compress them. While this process has a fair amount of problems and it's not considered safe (what if you accidentally delete your backup folder?), it is infinitely better than the no backup attitude.
3. • Third type is similar to the second but he saves the backups to the cloud or a network drive. If done right, this further improves the safety by storing backups outside the local PC. Doing it right is important: if you want to put it to a place where only you, or a very small amount of people can access it, otherwise it might not increase the safety but decrease it as others can alter or delete your files.

Software developers - such as ourselves at Omega Byte – face the backup problem at a significantly larger scale. In a typical project we don’t talk about one or two, or maybe a dozen files, but at least thousands of them, so we can’t just simply compress all of the files because that would clog our hard drive or network storage way too quickly. Also during the development the files in our project change rapidly.

Ideally everytime we develop a new feature, fix a bug or rename something we should do a backup no matter how big the change was. Not doing so means that when we finally decide to do a backup we will end up backing up multiple changes at once. That's never a good habit because if we accidentally introduce a bug then we either roll back all the changes (including the good ones) or we need to debug this new bug instead of just returning the previous state which didn’t have it. The third challenge is that writing a project is almost never a one man job. Multiple developers have to work on the same file set without interfering with each other.

That's just not possible with the traditional backup methods.

Lucky for us, this problem was already recognized in the early eighties, and solutions (some more successful than others) were created under the collective name of Software Version Control (SVC). SVC is so essential that I strongly believe that no software development team can be successful without having it. Moreover, having a SVC process in place could be more important than the programming language itself, as most of the problems can be solved in many programming languages but not having SVC greatly increases the chances of bad code quality, late delivery and project failure. Before explaining the theory it's worth mentioning that none of the operations below need to be done manually, there are applications developed to do that for you. Also while an SVC can store your backups on your local PC this use is not common at all, in the vast majority of the cases the backups are stored in the cloud. Using an SVC goes like this:

1. The developer downloads the project from the server (called: checkout)
2. Makes changes some of the files
3. Create a snapshot of the changes (called: commit)
4. Upload the commit to the server (called: push)

And this is where the SVC shines: once you make your changes the SVC doesn’t back up the entire project, just the files actually changed. Imagine that you work on a project which has 1.000 files and you need to fix a typo in a dialog box. By using an SVC you don't need to push all the 1.000 files to the server, it's enough to push the one changed.

A brief description (called: message) can be added to each commit which summarizes the change. In most cases when we take a look at a list of commits we are not interested in the actual changes in the files, but we’d like to see just a quick sentence about what changed so we could understand why that given commit was created.

Once you push your commit to the server your commit is protected against accidental data loss as once a commit is created it can not be altered or deleted. You can return to any of the commits anytime so you can restore the previous state of the project if that's needed.

To address teamwork: SVC allows developers to collaborate. As the commits are stored on a server nothing blocks the developers from checking out the same commit to their PC and work on the project simultaneously (called: branching). All of them can work on different changes and push their changes to the server.

The simultaneously created changes can be merged later.

As a brief summary:

Backing up our files is important to almost everybody. SVC is a sophisticated backup process which can be used by everybody but is a must for software developers. At Omega Byte for SVC we use GIT, which is the choice of over 96% of the professional developers. (https://survey.stackoverflow.co/2022/#section-version-control-version-control-systems). This article is a high level description of the SVC process so the terms were used vaguely. A more technical document will follow.

Feel free to contact us with any questions you have about this topic.