Choosing a version control system: git vs SVN, part 2

In the previous part, I described why do you need and what on earth is a version control system (VCS). In case that you are not familiar with VCSes, I introduced a bunch of useful terms and common concepts that would form a general idea for you about them. This part is all about comparing two VCSes of different models, so hopefully, you did play around with a VCS as I asked - real life experience is always helpful, after all.

This part is all about comparing two VCSes of different models, so hopefully, you did play around with a VCS as I asked - real life experience is always helpful, after all. Also, I stay focused on discussing collaboration ability of two tools. If you are working alone, honestly the chosen tool would not cause any critical annoyance.

git

git is a distributed VCS. Simply put, there are more than one repository (for convenience's sake, I will use the shortened term repo from now on). The repository that is stored on a server somewhere (in your local network, or an online server that you bought or hired) is called remote repo. The remote repo is the place that team members would go to get the newest version of the project, and it is copied into their local machines' local repo.

This means, when you commit a change, you are committing to the local repo. To make your changes visible online for whatever purpose such as backup or teamwork, you need to push them to the remote repo. In order to have your changes in other local repo, its owner has to pull from the remote repo.

Distributed version control system model.

Ever heard of things like GitHub, GitLab, or BitBucket? These sites provide free hosting services for git repositories. GitHub is a social network for programmers and anyone who is interested in their code. GitLab and BitBucket offer free private projects for those who do not want their code to go public.

Another thing that worths mentioning is that git is built around the concept of branching - this means you can freely experiment your ideas, without worrying about messing up your stable code. As I stated in previous part, branches are developed independently. Imagine the prospect that you are trying your nice and interesting idea, while your teammate can either continue maintaining current code or implementing his or her own stuff. Isn't that pretty cool, huh?

^ said Jesus himself. True story.

A drawback is that git has many options that can only be used with command-line interfaces. Many GUI available git clients, such as GitHub for Desktop, SourceTree or GitKraken are more non-programmer-friendly, so they would hide those options in order to keep a nice and clean interface. Also, I've found that I can grasp git's concept much better when I started to learn to use CLI than using GUI.

In short, I believe git is for your team if:

  • Your team likes to keep the development process going while keeping the ability to experiment.
  • Your team doesn't want to spend much for a VCS solution, so they prefer to have free services, including hosting options.
  • Your team is not afraid of the extra complexity of a distributed VCS, compared to a centralized VCS, such as SVN.

SVN

Unlike git, a distributed VCS, SVN (a.k.a. Subversion) is a centralized VCS. While distributed VCSes have more than one repository, a centralized VCS has only one main repository. Workstations of team member contain their local working copy, and when they commit their changes, they are committing directly to the repository on the server.

In my experience, the model of centralized VCS is much easier to understand than that of distributed VCS. All you need to know is that when you make any change, you have to commit so that you and everyone else gets the updated version. This is very simple, and even non-programmers can understand this very quickly and easily. However, committing directly to the main repository is quite dangerous, since it can crash the project that your team is relying on.

I love the ability to work on parts of the main repository of SVN. To make things clear, this is a quite common way to organize resources of a game dev project:

CoolProject
--- Assets
------ Models
------ Sprites
------ Animations
--- GDD
------ Characters
------ Levels
------ Mechanics
--- Source
--- Misc.

The Assets folder is created to store raw creative resources that your artists are working on. Your teammate artists will very unlikely to care about what you did with the code, while the designers would not give a shit about the sound engineers changed the chord of the main theme song. So the artists only need to check out the folder Assets to their working copy, without bothering what is going on in other folders. When a programmer needs, say, the newest sprite of the character, he or she just simply check out that file. This means SVN keeps works of individuals independents of each other while keeping the ability to update changes when necessary.

Unfortunately, SVN isn't built with a good support for branching mechanism. When you create new branch within SVN, it literally copies all current files to the new feature branch. When you merge back from the feature branch to the main one, SVN would check the content of every file in two branches. That is to say, branching with SVN is truly the pain in the ass. In contrary, git only stores deltas of differences, for example in commit #2, the file A.h changed in line number 10, with a plus becoming a minus. It applies the same approach when it comes to branching, and as a result, branching with git is much smoother.

In summary, I think SVN would serve your team well if:

  • Your team doesn't think experimenting with branching is a must-have requirement.
  • Your team likes the idea of checking out parts of the repo, rather than the whole repo.
  • Your team prefers SVN's simplicity and doesn't like to explain the concepts of remote, local, push, pull, etc for non-programmers.

On your own

There are a few great resources that I highly recommend you to read to understand more about these two VCS tools:

Git:

SVN:

In conclusion, git or SVN, they all have their own strengths and weaknesses, and I have discussed both of them above. Hopefully, you have much better idea about these two, and I'm glad if you have your own decision after reading my post. I would also love to have any comments here because I find this topic quite interesting to discuss.

Print Friendly, PDF & Email

One thought on “Choosing a version control system: git vs SVN, part 2”

Leave a Reply

Your email address will not be published. Required fields are marked *