Deciding which Source Management Tool to use

Introduction

I used like 10 different source management tools in my life. Different times, different corporations, different goals or resources where the reasons for all these different tools.

I started with file based SourceSafe 1998, used BMW's console based tools with drag&drop under Unix, used cvs, svn and git and some others I don't even remember. These are my conclusions.

Types of source management tools

There are many "types" of source management tools, but the - in my opinion - most important type is:

• Client/Server or
• Peer to Peer

"Client/Server" should be the standard for every corporation, tools like cvs or svn are like this. The users upload to the server, nobody but certain admins or nobody at all can modify what has been uploaded.

"Peer to Peer" is used by tools like Mercurial or git. In most cases you do not want this. This is a mode that is an advantage or a must have for certain situations, but for 99% of developers are client/server source management tools better.

Two main reasons:

1. security is normally a lot worse for peer to peer or does not exist at all
2. accessing only part of the repository is normally not a standard procedure for peer to peer (bad for game developers for example, do yo want to have your games and assets in multiple repositories or do you want to always have everyone download everything? Including the complete history? Nope? Client/Server you go then. Shooo)

Situation

Currently for most corporations, there is the choice between git and something else. The reason for this is a large group of people who never used anything else and are sure git is the best tool for the job. You used other tools and your opinion differs? They never used any other tool? Does not matter for these guys. "Git is the best!"

Let's get this out of the way. I was so happy to finally be able to use git in a large corporation in normal projects, because this is the only way to realize if the tools is good for the job or not. It is not.

Git sucks. Git sucks really, really bad.

Reasons why git sucks

• The most important item in my list is pretty easy for me, but perhaps not for others to see. I worked with a lot of people and many of them used many different source management tools during their lives. They just used them, like ... you know, the tools they are. Then they had to change to git and had no opinion about it. It happens all the time, the corporations tells you to use this or that tool, you do it. But these people suddenly had to use time for the source management. People who used this kind of tool for 10, 15 sometimes 20 years, they could not just use git, they had to invest time into it. And not just once to learn it. Again and again they had to use time, because git can get stuck somewhere, so you need an "expert" to help you. Most of them just rebase around until the code is valid again and the day is saved, right? Nope. Because you never know if you just lost code. Nobody really understands what caused the problem, few understand the solution, nobody can be 100% sure that no code was lost. This is not a guess or such, this is what happened multiple times. So, this item is kind of two items:
  • People, who can without problems use other source management tools, can't do the same with git.
  • Some "solutions" to git problems include changes to the code/structure of commits on the server. Nobody is always sure if HIS code is all there.
• Server side changing of code. This is really brutal if you realize it for the first time and you used real source management tools before. You can change committed code and even commits on the server. Perhaps I should say it again. You can change the committed code on the server. That is just... wow. It should not be possible but was not just possible but done in multiple git projects I saw. Some reasons for changing the commits were something like "if the history looks nicer you can take back a feature more easily". I am not making fun of you.
• Security of the repositories. It's not built-in. It's a clever use or misuse of other tools like ssh to create some barriers for people to change other's code. And no, again, not making fun of you. Git has no built-in security. Nothing.
• Don't use git for binaries. Yes, if you are in software development for more than 10 years and perhaps did not just write interpreted code then you will think this can't be true. No binaries? Are you fucking with me? Nope. Git is very bad with binaries, you should really not use git for binaries. So, in each and every real project, you should not use git. Because real corporations HAVE to archive the executables they release to their customers, have to archive the executables they use themselves to be able to reproduce bugs and be able to protect against lawyers. Normal products include resources like images, sounds or videos. Many products - like games - include many different types of binaries, like Meshes or Textures, there is NO way to not have to manage binaries. Now, some git morons really did the following: they introduced a SECOND management system, which is used just for binaries, then this only so they can keep using git. This makes so much no sense, I don't get why anyone would let such people do his projects. This is just plain stupid! Having to sync two different source/binary management systems is just not working. There are people in corporations to just manage ONE source management system, now they have to sync two different ones in a way all people who use it understand? Really? Fucking joke!
• Only use one git repository for one project. Do NOT put more than one project into one git repository or bad things will happen. So... you are a normal corporation and have multiple projects with a long history and different versions of these projects depend on your own growing code library, just like a REAL corporation, you know? Then git is not for you. Because git will make problems if you have such a situation. You can - of course - somehow do external linking to other repositories and .. yeah.. who cares.
• If you did the unmentionable and did put multiple projects into one git repository, haha, have fun when you realize that without tricks and even more problems you can not just check out a small part of the repository. You have to get it all. If the server's git repository is 30 GB and you only want locally some small files to edit, tough luck. You chose git, you lost.
• The most infuriating thing which can happen with git is the following: you pull from the server, merge the changes locally, push to the server and pull again to make sure you have the exact same status as the server. If you pull, nothing comes from the server to you because you have exactly the same current code as the server. Next morning you pull from the server to get the changes other people pushed to the server since yesterday.... you suddenly have to merge. Which is impossible! Totally impossible. Should be impossible! Should not happen! Which would be nice if it wouldn't happen... but you chose git. This is possible with git. And the answer I got in two different corporations from two different people as reason? "The reason you don't understand why this can happen, is because you don't understand how git works internally!". So.. this alone would be reason for me to NOT use git if I ever had the choice.
• There is one small thing I realized while working extensively with git, the naming system is (or was?) not logical. Sometimes you know there must be a command with THAT name which does THIS, but it is not there. Instead there is another command which can get the name you thought of as parameter. It is a real small thing but if you are already cursing then this seems not a small thing at that moment.

VERY small introduction to git

A git installation is

1. a git repository
2. a directory with checked out files

The git repository is a folder inside the same file/dir structure as the directory with the checked out files. So you can move them around at once without problems because they are both under one directory.

git has the following interesting features:

• peer to peer instead of client server (each git installation can be client and server at the same time)
• local 100% working repository, including merging, history and everything you ever used
• very easy managing of branches
• bad with more than one project per repository
• bad with binaries

VERY small introduction to Subversion (svn)

• Svn is client-server. Always.
• If the server is not reachable, you can't do things like compare to old versions, merge etc.
• Branching/merging works without problems
• Binaries are not a problem
• Checkout of a part of the repository instead of the whole one is normal, not the exception.

Use cases where I want git's features

• Multiple computers which might have to be used offline with access to all the features of a source management system and have to exchange repositories (like Home-/Office-PCs, Laptops in the train..)
• Targets for a push (copy code to a target) are unable to see the source- (start-) system. Examples would be Webpages which should not have access to the full repository or Virtual Machines which for sure are not allowed to access the host system. If you push your code into the Virtual Machine, use the Virtual Machine to process it, and pull it out from the Virtual Machine, you can do work on the VM but don't have to care for strange tries to access the "server".

I thought, if I just used git alone, without other people, then it might be stable, not strange bugs and errors, perhaps it will just work.

It did not. Same problems as with the teams. Normal operations, suddenly git does not like the situation and throws some errors at you. Completely unlike ANY other source management tools I have ever worked with, git really can strangle itself with just one user using it.

Alternative to git

Because of the above reasons I really wanted a working and usable software management tool with the good items from the git-feature-list but not the bad items.

And here comes: Mercurial. It has the advantages of git I wanted, but it never (so far) had the problems. It just works.

It sounds unreal and funny, but it is really that way. It just works. No weird errors, no rebasing or other stupid stuff, no need to understand Mercurial's internal working, because it works like all other normal source management tools, just like you'd expect it to work. No nonsense.

Conclusion

• Whenever it is possible, use svn (Subversion), because it is so easy to use, you nearly can't put it into an error state.
• If you need "git"-features, use Mercurial.

Simple, right? :-)