Version Control.

First I must open with the simple fact that a lot of people just don't use version control. The main reason for this is because in all honesty a lot of people just don't understand it. Not to mention the major version control war going on at the current moment just tends to confuse people all together even more. I am going to do my best to give some informative information on the different version control systems (VCS) out there to try and help make sense of the decision I need to make for my next project as well as hopefully help others make the decision for their projects.

First there are currently two types of VCS's out there at the current moment first is the CVCS and next is the DVCS. CVCS systems like subversion and cvs have a central server that every client must connect to. The client basically pulls revision information from these system to a working copy on your hard drive. These working copies tend to be very small because it pulls only the information it needs to be considered up to date basically the latest revision. The major gripe people seem to have with these types of systems at the current moment is the lack of enough information to do a proper merge of a branch back into the main code base. DVCS systems are what people call distributed. I hate that term because I think it makes things harder to understand. Examples of these are git, mercurial, and bazaar. The reason I hate the term distributed is because currently a lot of people use DVCS systems just like a CVCS system but with benefits. Typically the main code base is stored in a central location so that people can stay properly up to date with the code base. DVCS pulls the entire repository to your system including all of the revision history not just the latest. This allows for you to not be connected to the server and do everything right from your machine without a internet connection. What I like about this is in its own right everyone has a complete copy so if something happens to the central repository numerous people have a backup of the code and revision history. The nice thing about DVCS and why I think so many people are fanatic about it is the easy branching and merging. Because you have the total revision history it allows you to easily branch merge and cherry pick changes at will without a lot of risk of "pain". So when looking at the two different types of systems think CVCS (most recent revision only in working copy), DVCS (total history in working copy).

*Warning opinionated*
My main gripes with the current arguments out there have to do with the fact of branching. The DVCS group of people seem to like the idea of branching every time they make a code change or add a new feature. They argue that this is insane and painful to do in SVN because of horrible revision/merge tracking. Ok I agree branching and merging can be painful in subversion but at the same time it is not as bad as people say because they are taking it to a extreme and not using the system properly. I am not the kind of person that likes to make a branch for every feature I add into a application. I feel branching should only be used for major changes, re-factors, and other changes that have a large chance to BREAK the current working development tree. Maybe this mentality is why I never really had to many issues with subversion to begin with when it came to branches and merges. Maybe it is because I was using subversion as the developers INTENDED according to the svn red-book. I don't know maybe I am just a hard sell.

So which one should you use. It is hard to say each system has its pros and cons as you have seen. The one feature I love about the DVCS camp is the speed at which you can get up and running and the fact that sites like GitHub and Bitbucket are amazing places to host your code. I also like the speed of DVCS systems, because you are doing everything from your local machine and not over a network DVCS is blazing fast compared to CVCS. Lastly the thing I like the most about DVCS is the fact that they are very flexible and you can use them with whatever workflow you desire. The main cons I have for DVCS are the lack of repository permissions, large file support is really not that good because of full repo history pulls, no locking for binary files and other code files to prevent major issues if both are modified at the same time. For example if you only want to branch when you feel something has a good chance to break the entire main line of development you can do so. If you want to be considered the central repo instead of a host like GitHub you can do so. What I like about CVCS is the fact that it can handle very large files quite well. Another thing I like is the fact you can have repository permissions making sure you know who can write to the repository. I also like the fact that you can lock binary files and other files if you wish to prevent other people from making changes to the file as you make your changes. This alone can save tons of time if you are working as a team and your art assets are in version control with your code. The major issues I see with CVCS are the required network connection and can cause speed issues *coffee anyone*, not having the full revision history present on the machine making it difficult to cherry pick or inject merges into different parts of the development line.

Keep in mind the pros and cons are as I see them other people may have different pros and cons. Yes I listed less cons for subversion however, there are times when these cons can definitely outweigh the pros. The cons of DVCS are hard to ignore and can outweigh the pros at times as well. So with these things in mind I am sure you can better make the decision you need to make. As for me I have used both and I like both a lot which make the decision for me extra hard. The one big pull factor for me is hosting and DVCS has the huge win there. So for my next project I will be using DVCS because I feel the pros outweigh the cons more so under most circumstances. Not to mention I really like the speed and the fact of having a whole repository backup on my machine. Ultimately the decision is yours but with this information hopefully you can weed through the google fluff that is out there.

In the future I just might have to return with my experiences and if anyone wants more detail into the inner workings of Version control systems let me know in the comments and I will go out and find the video that goes into the details of the internal differences of how revisions are stored.