Top 10: Why Subversion is better than Git
[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…
January 15th, 2010 at 07:06
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.
January 15th, 2010 at 07:59
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…
January 15th, 2010 at 08:37
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.
January 15th, 2010 at 09:03
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
January 15th, 2010 at 09:22
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.
January 15th, 2010 at 10:19
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
January 15th, 2010 at 10:21
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.
January 15th, 2010 at 10:59
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!
January 15th, 2010 at 11:17
[...] (Read more) [...]
January 15th, 2010 at 12:38
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.
January 15th, 2010 at 15:46
[...] This post was mentioned on Twitter by José Valim, Maurício Linhares, Carlos Mendonça, kesjam, Puzzle ITC and others. Puzzle ITC said: Why #Subversion is better than #Git: http://blog.cedarsoft.com/2010/01/top-10-why-subversion-is-better-than-git/ Must read!
[...]
January 15th, 2010 at 15:56
I am hoping that you are being extremely sarcastic here?
January 15th, 2010 at 16:26
hehehehe! I like this joke alot!
January 15th, 2010 at 16:29
Оne of the big drawbacks is the svn folder “. svn” in each directory. Pros simply fade
January 15th, 2010 at 17:08
@Feu Teston
If I had read the this article, I would remove my comment.
January 15th, 2010 at 17:21
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…
January 15th, 2010 at 17:31
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.
January 15th, 2010 at 23:39
If I miss VSS?
Well, I live in the check-in race everyday!
I’m the luckiest guy on earth.
January 16th, 2010 at 00:09
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!
January 16th, 2010 at 08:49
[...] Tweets about this great post on TwittLink.com [...]
January 17th, 2010 at 13:33
Social comments and analytics for this post…
This post was mentioned on Twitter by mid: Subversion unifies a team (or why Subversion is better than Git, haha) http://is.gd/6itCj...
January 19th, 2010 at 01:08
I love merging in subversion. Its almost as fun as chopping up onions…..
January 20th, 2010 at 13:05
[...] Top 10: Why Subversion is better than Git Just Java (tags: git subversion) [...]
January 22nd, 2010 at 16:28
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….
January 23rd, 2010 at 14:40
Hugh: I hope you are joking…
March 2nd, 2011 at 01:52
Whooooosh!
March 23rd, 2011 at 16:38
Is this post ironic?
I can’t believe that developers or managers like you still exist, in 2010… Unbelievable. You’r toooooooooo old. Deprecated.
September 7th, 2011 at 07:44
I wouldn’t normally comment like this, but I felt compelled to note that your article is a steaming pile of bullshit, I mean – “That sounds like some alternative to BitTorrent. I don’t support pirating!” is not a valid “point” in any argument. I could pick holes in all of your other points effortlessly, but I have better things to do.
September 15th, 2011 at 14:56
Nothing is more entertaining than watching people with broken sarcasm detectors go and have a rant… thanks for that.
September 15th, 2011 at 17:13
The troll within a troll… this is so meta.
September 23rd, 2011 at 23:02
it’s kinda sad how few people get dry sarcasm. i loved this post, hilarious and SO true!
October 20th, 2011 at 13:46
1. Branching >>
You dont know what you are talking when you say branching is unnecessary.
What is the largest member size you have worked with for a project ?? 3 / 5 / 7 / 8 ?
I am currently working with 35 developers working on the same project across globe (India, US, Australia, Argentina). And there we need to have branching. Its impossible if everybody starts to commit their code, just because iit may conflict tomorrow, without there changes being stable, it would be a complete mess.
coz otherwise svn sucks at conflict resolutions on such a large cases and branch management in git makes it so easy.
2. centralized >>
versioning systems are code repositories and meant for programmers to make code base dveleopment manageable. Nobody cares if managers find it difficult, as long as it helps immensly versioning and managing codebasae development.
Managers would even love to go ahead with traditional of programming, as it is quick way of finishing project, does not mean developers have to give up on oops, where it helps in longer run.
Similarly, if managers like svn just because of centralized versioning, (then F**k them) does not mean, it needs to be that way.
makes sense ?
3. Easy to Use >>
Well, Opps vs traditional way of programming again can be a great example here. Usability matters over simplicity all the time when it comes to complex programming. If you cant digest complex things, give up programming and find another job. Dont call yourself a techie.
4. File Locking >>
File locking system has its own disadvantages, which i dont need to repeat. Branching and decentralization makes life easier in git. again large number of programmers working on same system across globe , and one forgets to unlock a file … downtime is costly in such cases. Use branching rather for every small modules.
5. Frequency of releases >>
. Seems to me that Git has been stable since very long time as they dont frequently release new things.
Does not that suggest itself subversion was not a complete tool ?? and must be little unstable, as soo many releases are coming out
6. Merges are forced immediately
What if my current changes are still unstable, and can break the repository functionality. Would not that mess up other 34 guy’s work at their end if iam forced to commit ??? Does not it become disadvantage that time ???? Thats bullshit constrain.
I guess you are seeing only one side of coin dear.
October 29th, 2011 at 15:43
Honestly this is one the most miss-informed posts i’ve ever read. To claim theres an industry standard for VCS shows at best a lack of understanding of the industry – however, if you went to any large organisation with a real code base and said that they’d laugh at you (google, apple, microsoft, oracle, cisco, the list is endless) and I can only assume you’ve never worked on projects with more then 5-10 people. Subverison (or cvs) certainly dont come close to solving all problems, they just do not scale. Interesting how you compare how often git releases to how often cvs/svn does given that their release ideals demonstrate fundamentally different ways of thinking not related to the stability of their code (again, a lack of understanding imho).
File locking? well, again, lack of understanding about the philosophy of how de-centralised repo’s work (versus concurrent).
Do you really want the last person who commits to deal with your merge? are you even serious? I can only assume thats actually a joke.
As for a central repo – this probably demonstrates how much you’ve miss-understood git (or how its supposed to work). Consider kernel.org as an example, everyone pulls from the main kernel tree (that linus owns) and yes they do commit locally, but what happens then? they then push back to their *OWN* git repo’s at kernel.org (I think you missed that last and most important part) – theres still a central archive with EVERYONES work in it, its in different repo’s, but its there. The best part of all this is that merge’s get handled sanely and cleanly into the main kernel tree.
Lastly, the first part of the article makes me believe perhaps this *IS* actually a troll/tounge-in-cheek view of svn and a list of the reasons why its actually bad. But i’ve stumbled across it a couple of times when “young” folks to the coding industry are arguing about svn and it so very much annoys me these days to get an email with a link to here in it.
January 19th, 2012 at 07:48
obvious troll is obvious
January 20th, 2012 at 17:08
truly, you need to use git and then you will be deemed fit to make your comments.
Go ahead, dont be afaid, try it.
I am sure it wont hurt
January 25th, 2012 at 13:18
Wow. This post is really old now…
But even with disclamiers at the beginning and the end of the article, nobody is able to detect the irony…