Top 10: Why Subversion is better than Git
- January 14th, 2010
- Posted in Java
- Write comment
[Update:
I have received a lot of attention. Thanks for that. But obviously not everybody has detected the unobtrusive irony this article might contain...
So please reread this article one more time before you:
- Link this article to your Subversion-Blog
- Try to convert me to Git
- Use the arguments in a real discussion
But the reactions I received, prove that I have mimicked some *real* opinions very well. And that really makes me sad...]
There are many blog posts out there that try tell you why Git is better than Subversion. But very few that tell you why Subversion is better that Git. As expected: You don’t have to state the obvious…
1. It is industry standard
Subversion is more widely spread and better known.
And it is a good idea for every business to rely on the “industry standard”. Therefore it is strongly recommended to use CVS (the real industry standard) or at least Subversion. But please stay with version 1.4. That one is well tested. And the new stuff probably has many bugs that just wait to purge your repository (and all backups).
Prove: Just compare the frequency of releases
The last CVS releases have been 1.11.22 on 2006-06-09 and 1.11.23 on 2008-05-08.
Subversion releases a new version about every two or three months (1.6.6 on 10/22/2009, 1.6.5 on 08/22/2009).
But Git: They release new versions every few days! They have so many bugs and so few features that they are forced to release even the smallest improvements immediately…
Remember: Fewer releases represent greater stability and more features.
2. Central Repository
Subversion has a central repository. That is what everybody wants. Every manager wants to know where the code lives. With subversion you can take his hand, guide him to the server room and point to the server.
That is what managers want.
That fancy “everybody has the complete repository” is not a work flow – it is communism…
“Distributed Version Control System”
That sounds like some alternative to BitTorrent. I don’t support pirating!
3. Subversion is easy to use
The developers I have met so far, don’t understand complicated (read “command line”) tools. I don’t have to talk about web designers or sales people here…
Subversion has a nice UI (Tortoise SVN). The developers can use that UI. And they don’t have to understand the complex mechanisms of VCS. Just a click here and there is enough (see “Branches are evil” for more details).
If a problem occurs:
4. Subversion supports a single strategy that solves all problems
And if any problems occurs, those can easily be solved in Subversion: Just copy your modified files away, make a clean checkout and merge the files back manually.
That is all. No fiddling with branches, command line and such stuff.
5. Branches are evil!
Forget about creating branches (or – even more dangerous – merging). Branches are just useless and a sign that your team is not coordinated well.
Have to do critical stuff on the trunk (e.g. performing a release)? Just shout to your colleagues to stay away from the repository. Development may continue locally. And if the things take a little longer – no problem – the bigger their commits are, the better.
Maintenance branches? Come on. Have you ever seen us releasing a service release? And if really necessary: The forward-looking developer keeps a directory on his hard drive containing the sources the release has been build from.
6. Empty directories may be added
I really love organization. And I hate one thing: Anarchism. Anarchism and communism. Okay, I hate two things: Anarchism and communism. And bleeding edge…
And Subversion allows me to create a good and clean and complex directory structure. And commit it. And then check it out again. The directory structures I create usually are so helpful that everybody *must* see them immediately – just as inspiration.
7. The help is clear(er) and *much* shorter
Just compare the help pages for “svn log” and “git log“.
While Subversion just needs one page to document all features, the git documentation is insane long… Git is much more complicated. Even such a simple command needs hours to just read the documentation.
I’d go as far and say, that it is impossible to use Git without professional training of at least several days. And that is the hole point of that OpenSource/communism stuff: They try to cheat you to book expensive training…
8. Supports file locking
Do you miss the times of VSS, too?
I really hate that situation: I try to commit and have to notice that someone else has changed the file I worked on. This is ridiculous. Why should a colleague be allowed to change a file, *I* am working on?
So Git guys: First solve the locking issue and then come back.
9. Expandable keywords
I really love expandable keywords. In the old CVS days that has been my favourite feature. Okay, I don’t have a real use case, but I love to see the the magic happen.
10. Merges are forced immediately
Yeah. The killer feature of subversion.
I have to admit that maybe file locking is not the solution for every case. But at least each developer has to be forced to merge all changes before he is allowed to commit.
I hate those guys that work all day long and then try to commit their changes just seconds before they leave. And – additionally – they are very focused when they merge changes to their uncommited work. Knowing that each step might destroy the work of several hours is a great motivation.
This feature often leads to check in races. The first commiter wins, the second one has to merge. And that is worth cash: Developers are motivated to work as fast as possible.
And one more thing I love: If you are leading the check-in race, you can keep your colleague merging for a long time. Commit – file has changed in repository – update – merge – trying to commit – file has changed in repository… I could do that all the day…
Conclusion: Subversion unifies a team
Disclaimer: I really like Subversion. I have used it for several years. And I know branching has been improved dramatically in version 1.5. So this post is not a rant about Subversion but instead about those people that refuse to take the next step. Those people that prefer CVS over SVN, SVN over any DCVS and so on…
Man, please try git on a real project. Once you use it you will see how it makes your life better. With performance and also with no problems on merging stuff. You do not need to use branches or other stuff, but it simply works. On svn branching, tagging and merging is a pain. On git it just works. Fast. If I wrote this article I would remove it from my blog after trying git.
Threaded the needle with this post, well done. I entirely expect dozens of pro-SVN people to link to it… I wonder how many re-reads it will take before it sinks in…
One of the main features that I love about Subversion, is the ease of branching. We use it all the time in order to support existing releases well, and branches in subversion are easily understood and easily handled. It’s great.
Also, we prohibit the use of locks in our subversion repository, because locks reduce productivity. However, you’re right, that locks make it easier to convert teams from other source code management systems that use locks all the time.
Branches are evil!???
I strongly disagree. with branches all the members of a team can switch easily between diferent versions of a project and correct the bugs of previous versions.
“Development may continue locally” yes if your team is small and is not distributed in several countries around the world
Fewer releases may also be an indicator for the near end. CVS lost its popularity and most new projects are using Subversion, Mercury or Git.
Hi there,
I just came across your interesting blog post here via my twitter feed (along with a number of similar ones recently but yours is by far the most informative!) and enjoyed what you had to say!
I manage a Subversion Community Site whereby we aim to provide a one stop solution for as many Subversion users as possible, offering forums, blogs, news articles, wiki and Subversion downloads. It would be great to see you there, sharing your views!
I hope to see you on our site at some point in the future
http://subversion.wandisco.com
Cheers!
James Bailey
Any opinion is arguable, but you unfortunately do not argue that seriously. Guessing the frequence of bugs and stability out of releases like you do in 1.) is just not serious. But 5.) ‘branches are evil’ is pure nonsense. Your point of view might be practicable in projects that have limited customers and limited time slots. As soon as you have to maintain a long term product (I commit on Eclipse CDO, we have a 1.0, a 2.0 and a development branch) there’s just no other choice that branching code bases for the different incarnations you released.
this post is idiotic. between word we can read you like working in stress, the more stressful work is for every one the better, you are windows guy(?)(you like restarting everything – do you try to repair your car by trying to get in again?). the idea that it is better that you may destroy your work is great! it is even better with idea about immediately committing – “i’ll commit it now, so i don’t have to resolve any conflicts and i will test it later”. oh and you have blog. they are used as porn platforms you pervert!
You are right when claiming subversion is better in ease of use, better documentation and so on I strongly have to disagree with the other points. Why are branches evil? You didnt really argue here. If you havent used release branches yet you didnt work on a real product with versions. Yes they are hard to handle with subversion, but with git you think about branches very different. I create a branch for every bugfix I do. Switching between them is very easy and fast. You have a lot of more power than with subversion. You can rebase branches and cherry-pick single commits for instance. But of course with more power comes more responsibility and you have to learn a bit more. With git you have also more choices for your workflow, if you want a central repository, fine, you can have it. But why should it be bad to have more choices? Filelocking just sucks in my opinion, they just keep you from working. But you need more power when merging your changes back. And empty directories, yeah, right, okay, but in real life, thats not a real problem. And industry standard is not an argument at all otherwise you wouldnt code Java but C++ or Assembler.
I am hoping that you are being extremely sarcastic here?
hehehehe! I like this joke alot!
Оne of the big drawbacks is the svn folder “. svn” in each directory. Pros simply fade
@Feu Teston
If I had read the this article, I would remove my comment.
Thanks for all comments. I have read them all. Don’t want to answer every one apart.
Please check the update I have added. That should clarify the post…
Sorry for the confusion. Next time I will point out the irony…
Branches are evil?? “Branches are just useless and a sign that your team is not coordinated well.”
Come on, just coz you want to make 10 points, you can’t add anything and everything that comes to your mind.
If I miss VSS?
Well, I live in the check-in race everyday!
I’m the luckiest guy on earth.
Bah, you should remove any hints/notes and just let the comments flow, entertainment value will be huge…
I want to see the comments supporting your no-branching policy… don’t ruin all the built up entertainment value!
I love merging in subversion. Its almost as fun as chopping up onions…..
This is great, made my friday!
At work we use CVS and we in fact do have branch meeting to decide when to branch, including the shout over the cubical wall to initiate the branching….
Hugh: I hope you are joking…