Version control systems - DevLog #007

Some weeks ago,

we had the discussion, why we use Apache SVN. Many of our colleagues are using git as version control system and they're used to it. Many developers on git breath the soul of this version control system and they like its powerful features, which return many freedoms. And this might be one of the major issues in the discussion around SVN and git: SVN seems to restrict the freedoms of their users. I do not want to argue against it, because it's true. But it's not always an issue.

The issue with freedom

Freedom always comes at a price. This price is responsibility that you take for all your actions. Freedom may offer you great opportunities, but it also requires that you always think about the consequences, which you might face. Thinking about version control systems: git offers many freedoms but it also requires your attention while working with it. If you decide to push your changes in another order than the historical one (which is possible) you might break the corresponding branch in all other repositories. If you do not push all your changes, you have a local version control but you will lose all your code, if your hard drive fails (which happened to me a few years ago). So you're responsible for archiving your code revisions by yourself.

Although I like freedom and the responsibility coming with it, there are some cases, where I perfer to push away the responsibility: version control systems are one of them. I simply do not want to think about what's happening in my repository. I simply want it to work and if that restricts my freedoms, I willingly give that away for a repository system, which cannot be broken by its users.

TLDR: I prefer Apache SVN, because it restricts the actions, which you can do with it. It is just simpler than git.