Version Control Systems and You! tutorial

Usually, when it comes to modding, many newcomers have a hard time keeping track of issues, source code, and assets, and what usually ends up happening is one person keeping track of everything, and more often than not this is the mod leader. And when a project lead isn't leading but is merely managing the assets, you've got a huge problem. Hard drive failures, files being lost in translation, and worst of all, people dropping off the map, can contribute to a mod dying faster than a headcrab in a fire.

But don't give up! There's a solution. It's call a VCS or Version Control System. There are many different types to choose from, each with their pros and cons, which LUCKILY will be discussed in this article, not only saving you time researching for the best VCS for your project, but also laying them out nicely so you can discuss it with your team. 

So, let's get started. In the world of VCS there are two types of VCS, centralized and distributed. Before we get into the actual different revision systems themsevles we're going to discuss the difference between these two models, as well as when you would want to use them. We're only going to mention free and open source software here, so I'm not going to talk about Perforce, or anything like it. 

Centralized Version Control Systems

The centralized model is the VCS that is MOST familiar with mod developers today. If you aren't running at least an SVN or CVS repository for managing your code then you might as well just shoot yourself, because you're only a part of the problem. While CVS and SVN are effectively the same thing, and SVN is loads better than CVS I'm stil going to talk about it. The way a centralized VCS works is actually quite simple. There is a central repository for all objects. This is where the final build goes. It is the master version. End of discussion. People who have access to the repository update, make changes, and then commit their changes to the central server (hopefully in a way that does not cause a conflict).

Distributed Version Control Systems

In recent years, the distributed model of version control has become the most popular model of version control for open source projects. There is no reason why you can't adapt it to suit your project's needs. The distributed model is interesting. You pull, or "clone" the existing main repository locally, create a new branch, and then commit. Later on your work, once deemed stable is merged back into the main branch. Unlike the Centralized model however, where there is only one central main branch for use, there can be as many branches and as many clones as you want for your code. In fact some VCS encourage this behavior. The distributed model also usually has a much easier time merging code and assets, allowing a minimal amount of time updating your master branch, as opposed to the centralized model where it can sometimes take several hours to properly merge everything. Another great thing about the decentralized model, is if the central repository ever goes down, or is corrupted or is lost, you already have an easy to use backup. Or, if a programmer in an act of rage destroys your repository (not as in a wipe but removing it from the server, or access to the server or what have you), you still have your source code. I know of at least one mod that this has happened to. (It shall remain unnamed to protect each prospective parties).

So now that you undersand the difference between Distributed and Centralized Version Control Systems, we can actually get into who uses what, and when. Let's get started :D