Why Subversion Scares Me
Table of Contents
For many users, version control has long been a scary thing. Because committing your code inevitably meant sharing it with the world - imposing all its bugs and flaws on your poor teammates.
However, this is only true for centralized systems like Subversion. In a modern VCS like Git, you can let go of these fears.
In Subversion, committing new code is a terrifying act. This is because of a combination of two facts:
- (1) Committed code is automatically checked into the central repository and thereby instantly shared with your team.
- (2) New code (by nature) contains bugs and the potential to conflict with code from your teammates.
Therefore, committing code in Subversion effectively means one thing: you risk to introduce bugs and/or conflicts into your team's common codebase.
This should be frightening to you - and in fact it is for a lot of people.
How do people deal with this unease? By not checking in new code for days or even weeks. And even then they only dare it with a senior developer holding their hand. People are afraid of using version control - or at least they don't appreciate the thrill they get when performing something as simple as a commit.
In newer versions of SVN, you could create feature branches to circumvent this. However, it remains a workaround, not a true local commit like in a distributed VCS like Git.
Committing Infrequently Causes Problems
As if all that sweating and the nervousness when having to commit wasn't bad enough, there are other problems caused by committing infrequently:
- Code gets shared with your teammates very late. It seems as if the project wouldn't move for days or weeks and suddenly makes a huge leap.
- Sharing infrequently means everybody introduces larger sets of changes at once. This dramatically increases the likeliness that some of the changes conflict with each other.
- Large commits that contain many changes (maybe even from different topics) are hard to understand - for your teammates and even for yourself after some time.
Committing with Confidence in Git
In contrast, let's look at how a distributed VCS like Git behaves. To say this early on: #2 won't change. It remains a fact that new code contains the risk of bugs and conflicts. However, the big difference is that committing doesn't mean imposing these potential bugs and conflicts on the world!
A commit in Git saves your changes to your local, private repository. You can decide later - possibly after making other commits, reverting some changes, or discarding others - that you want to share your work with your team. Work that has been thoroughly tested, integrated, and proven to be what you want after adding more code.
Also, conflicts can only occur on your local machine. You cannot bring the central server to its knees by adding an innocent change. There's really nothing to fear in this regard.
Version Control Becomes a Helpful Tool
I guess I don't have to explain why it's great to know that you're not imposing bugs and conflicts on your teammates that you potentially produced with your new code. However, once you begin to lose fear of version control you'll find that it's in fact helpful, not a heavy duty.
Instead of making commits only when you can't avoid it, you can start to make commits often and in a very granular way. Commits are no longer just a means to integrate your code into the main repository. In Git, they are a way to structure your work in a way that allows you (and others) to...
- easily understand what was changed
- collaborate with others in a very carefree way
- quickly roll back bad code in case it's necessary.
Bloated, "weekly" commits cannot fulfill these purposes.
These facts can make the difference between a chore and a helpful tool. I know many developers that changed their minds about version control - recognizing it as a tool that helps reduce the chance of mistakes and improve the quality of their coding.
