Souring on SubversionOne thing that has made me lean more positively towards Git is that Subversion’s warts have become more apparent to me over time. And they are not going away any time soon. For example, the convention-based approach to branching and tagging or the ability to do subtree merges makes it all too easy to paint myself in a corner. There is still no real support for moving/renaming (WC tracking does no count). These are not weaknesses inherent in centralized VCs, but they are glaring weaknesses found in the dominant centralized VC, Subversion.
What is most frustrating, however, is the abysmal pace of Subversion progress. When I last blogged on this subject, I pointed out items on its roadmap that would gain some of DVCS’ features: shelving and checkpointing. That was in 2010. It is now 2014, and these features as well as much-requested features like rename tracking and improved merging remain deferred far out into the distant future. If you want to use Subversion, you should be prepared to appreciate it in its current state, because it’s not going to change much over time.
The Github experienceI had assumed that Git’s advantages was only in its distributed nature, the D in DVCS. Consequently, while that might be great in distributed environments like the Linux kernel development for which it was invented, I did not think it would be useful in a typical commercial environment. After all, we wanted a central location for our code, don’t we?
As it turns out, Git works great in a CI pipeline environment: code could be qualified and promoted to different repos as it is deemed ready. Moreover, Git on Github (and similar services) offers something hard to do with plain Subversion: an integrated, structured code review process. The ability create pull requests that team members can view, comment on and selectively merge (if you are authorized) opens up team interaction possibilities not previously possible under the old model. This team code review facility is the single biggest draw for me.
While the Git command line is cryptic and the changeset IDs remain opaque, I’ve found that TortoiseGit has smoothed the learning process for me. Its similarity to TortoiseSVN has made the transition much easier for me.
It’s not all rosesBut Git continues to have its rough edges, and they remain rough over time. For one thing, the conceptual complexity of a DVCS remains. Consider what it takes to get your changes into the Subversion repo:
- Pull request
- Merge (on Github)
Unfortunately, some people struggle with merges. I’ve seen colleagues waste a ton of time struggling with merge issues. And their struggle can quickly become your struggle when a botched merge or someone doing a “push –force” causes the shared repository to seemingly lose a week’s worth of the team’s commits. Oops, time to call our Git guru. It can be rough going for people who would rather expend their brain power on their code rather than their tools.
Someone has said (paraphrasing roughly) that Git is sort of a Swiss army knife with a live chainsaw and many sharp pointy edges attached. I heartily agree. I’d summarize my attitude towards this powerful tool as follows:
Git makes easy things hard and hard things possible.