Practical Reasons To Choose Git Or Subversion?

markmcb writes "I develop Rails applications and recently followed my lemming herd and made the switch to Git after learning some of the practical advantages Git offers over Subversion. As I'm sure there are many die-hard Subversion fans in the Slashdot audience, I'm curious what your key reasons are for sticking with Subversion. If possible, I'd like reasons that apply to 'most of the time' as opposed to arguments based on obscure features that may get used only a few times ever."

Comments

Blah

[Anonymous Coward]

You can have my cvsroot when you pry it out of my cold dead fat hands.

Windows.

[scott_karana]

Git is an excellent piece of software, but Windows performance is not so great. Git is too UNIX centric to be fast on Windows in the near future.

Other distributed SCMs often are interpreted and just as slow as git (on any platform), so this might not be a concern for me.

Re:Windows.

[Just Some Guy]

Git is an excellent piece of software, but Windows performance is not so great.

Git could paint your house and buy you a girlfriend, but that wouldn't help Windows.

Re:Windows.

[Daniel Phillips]

Mercurial is slower than GIT on Linux

Sometimes slower, sometimes faster, usually about a tie in my experience. Measurements on kernel tree import and initial commit showed roughly a tie.

But Mercurial is _way_ more obvious and pleasant to use than Git. I use both, but any time I have the option I choose Mercurial.

Re:Windows.

[ozamosi]

Git could [..] buy you a girlfriend

Dunno 'bout you guys, but that right there settles it for me. Git it is!

Re:Windows.

[syousef]

Git could [..] buy you a girlfriend

Dunno 'bout you guys, but that right there settles it for me. Git it is!

Congratulations. Your new girlfriend's name is 'Richard Stalman' and you can call her 'RMS' for short.

Enjoy your new girlfriend.

Yours faithfully,

GIT

IDE Integration

[FortKnox]

Like the bi-line suggests... Unless you are coding in something like vi or emacs, I don't use the command line for my source control. IDE Integration means a lot... most of the items that git 'claims' to be better on is something IDE plugins fix. So the maturity of the plugin and the comfort with using it is a big thing for me. As such, I'm usually using CVS or Subversion.

Re:IDE Integration

[dubl-u]

Try merging a reasonably-sized branch with subversion (and you'll fail and cry and ask why oh why you didnt use git).

Simpler solution: stop merging reasonably-sized branches.

I know that's not reasonable for every situation, but about 90% of the time I see people doing lots of branching and merging, it's a response to screwed-up organizations or dysfunctional personal relationships. I saw one team move to git from subversion because, at the root, a couple of developers were arrogant assholes and their manager was a chinless milquetoast who let them get away with it.

That's not to say git isn't awesome for certain situations, mind you. But branching and merging adds a fair bit of overhead, and anything that increases a project's overhead should be your last resort, not your first.

Re:IDE Integration

[Niten]

That's not to say git isn't awesome for certain situations, mind you. But branching and merging adds a fair bit of overhead, and anything that increases a project's overhead should be your last resort, not your first.

Well OK, those principles are appropriate for traditional tools like CVS and SVN. Branching and merging adds a lot of overhead if your SCM isn't built to handle it. But once you've used a modern SCM like Git or Bzr, you'll know that with Git you literally cannot branch too often. Don't think of Git branches like you think of Subversion branches, it's a whole different playing field.

I have a rule of thumb with Git: every time I set out to implement a new feature, if I think it's going to take more than a single commit to bring into the mainline, then I make a new branch for it. Working on three different features at the same time? Then use three different branches, and switch between them at will.

So what's the big difference between SVN and Git that allows such carefree use of branching? There are a few points to understand:

• At one point, the SVN developers liked to make a big deal out of the fact that branching in SVN is a lot cheaper than it is in CVS. That's all well and good, but it doesn't mean much when SVN's handling of merges is so primitive. Git handles merges extremely well, in no small part due to the fact that, like Bzr, Git tracks content rather than changes. (If you browse through the recent history of the Linux kernel, you can witness 12- and even 20-way merges; with Git, merging really is no big deal.)
• In Git (and in Bzr), branches are not immutable, permanent parts of your repository. You can delete (or simply not push) branches when you're done with them. This means you're free to make as many experimental branches as you like in your own local repository; you can take advantage of the full productivity power of Git branches without immortalizing your failed experiments in the central repo.
• In Git (and in Bzr, but not in Mercurial), there doesn't have to be a 1-1 mapping of named branches between each copy of your distributed repository. This has the important result that you can name your experimental branch "experiment" in your local repo, without being concerned about polluting some global branch namespace. This does a way with a lot of the mental overhead associated with branches in SVN.

In conclusion, 90% of the time I see people advocating the use of branches only as a last resort, it's because they're using the wrong SCM =)

Re:IDE Integration

[musicmaker]

So I guess you've never worked in the real world, where corporate mandates a change that has to go out before EOB same day, or where you are half way through a feature set impl, and management changes the priorities. What do you do with that code then? Or when the CTO ups and quits, and his info has to be yanked from the website in 30 minutes or less.

Often you need three branches at least, one for dev, one for staging, and one for production. And that's not counting the system rewrite branch that might be bumbling along in the background perpetuated by another developer whose been assigned to fixing all the wrongs in the current system.

And let's not even start down the path of trying to integrate people's work in subversion who are in a big team when someone has gone three weeks without a commit because they are working on a major new feature. And that's not even starting to talk about database updates and how they have to be applied in the process between co-ordinating developers.

Then we can talk about the offshore development team who isn't trusted to put changes into the main branch without a peer review from someone onshore.

And then you get sued by a competitor who accuses you of stealing their code because you hired one of their developers and they have some random bit of proof, so you have to make a new branch to incorporate whatever random changes legal decides are appropriate to mitigate that, that have to be reviewed by an independent third party who takes three weeks to do anything, and you can't just stop development and wait for them.

And what happens when you have to update the docs that should be in version control too for someone else, particularly manuals for a release that is concurrent with ongoing development, or even historic because something somebody put in the manual six months ago has turned out to be wrong, and they have to be updated for that release that people are still buying.

Showing product to the client (because that's who really calls the shots, not the product manager) every few hours is just plain impractical. Most people don't want to see updates every few hours, they want a finished product in clear review cycles. They don't have the time to review the entire system every few days let alone every few hours. A full QA cycle for a normal sized product can last a week. Do you just stop development while they do a full QA before a release?

And let's not even mention bugs that are transient and may only show up six months down the road when more people start using the system, like race conditions which have become apparent in code that was written two years ago and nobody remembers for toffee. What about storage checking - the system was written by someone who thought that storage would never run out, so why check to see if there is enough space on the disk to complete the operation, and the application crashes and is down for a while while some poor sysadmin tries to find more disk space.

And the application that wasn't maxing out the network until it was deployed at a client with 300 users, and now you have to go back and rework your com model from a year ago. It's not exactly a bug, but you're gonna have to fix it anyway.

What about a large scale integration with a pre-existing piece of software that might take a month to complete? You can unit test each piece of it sure, but you can't release the whole thing until the integration is totally complete.

There are SO many reasons you have to have branches in the real world.

Familiarity?

[gorrepati]

Thats all there is it to it, oh mighty one!

Comment removed

[account_deleted]

Comment removed based on user account deletion

not 1:1

[sohp]

The most effective use of GIT happens when the team changes its mindset away from the central repository with multiple developers checking into it to a true peer-to-peer development team. I wouldn't switch away from svn until the organization I was with was prepared to "think different" and make that transition. Using GIT like a fancy svn just makes it like a complicated svn, not a better way of doing version control.

Real programmers

[David Gerard]

Real programmers type cat | cc and get it right the first time.

Re:Real programmers

[Waffle Iron]

Real programmers type cat | cc and get it right the first time.

Some of us don't have to cling to safety blankets like that. We prefer the simplicity of cat > a.out

Linus on Git vs CVS/Subversion/Bitkeeper/etc

[MrFreezeBU]

How odd that I was just watching a talk that Linus gave at Google. Link to the talk

Re:Linus on Git vs CVS/Subversion/Bitkeeper/etc

[doug]

Randal Schwartz, the Perl guru, gave a more detailed presentation on git, also at google. It has a lot more meat on its bones, and gives examples of using git.

http://www.youtube.com/watch?v=8dhZ9BXQgc4

Depends what you need more.

[Ant P.]

SVN is better for Windows users.
Git is better for Git users.

Git and SVN

[MemoryDragon]

Well hard decision, I live in both worlds, currently I use svn as central repo and git mainly for versioning local repos. Well both have their advantages and disadvantages. SVNs biggest disadvantage probably is the speed, and the model (which also is its biggest advantage for certain team structures) Gits biggest problems are: Almost total lack of tool integration into existing tools. Rather unstable and not well integrated into Windows. You have a load of data which resides on your filesystem (basically a full repo copy) while SVN keeps only parts of the metadata locally. Git however has the bigger advantage of having a very compact meta format so this disadvantage basically is nullified unless you have a huge codebase with thousands of revisions! I would not despise one or the other. I personally for a mixed team still would choose svn over git as it is currently, mainly due to the unpolished windows integration and lack of visual tool integration (yes git gui is known to me)

3d party tools - Trac and Tortoise

[Anonymous Coward]

Trac - One reason to use Subversion is the hard bindings you can get with Trac. Nothing enters the repository unless it is tied to a ticket. Ever been to a software process review? This is a must.
With the newer trac versions you can pass the tickets though the review stages and if you just wish to peer-review the code you can do that in Trac without checking out anything at all. Just click on the links in the ticket and you see a diff of the source in the webbrowser.

Tortoise - integration into Windows desktop. You can immediately tell by looking at the folder icons what needs to be checked in. Right click on a folder and select commit or update etc... For some reason this tools is so much better than anything on Linux...

Re:svn == unpleasant and maybe buggy

[CaptSaltyJack]

Subversion usability leaves a lot to be desired (although the book is really nice). For example, cd into a working copy that you've never seen before and try to determine its exact repository URL.

Uhh, ok.

$ cd tortoiseSVN
$ svn info
Path: .
URL: http://svn.collab.net/repos/svn/trunk
Repository Root: http://svn.collab.net/repos/svn
Repository UUID: 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a
Revision: 33826
Node Kind: directory
Schedule: normal
Last Changed Author: hwright
Last Changed Rev: 33826
Last Changed Date: 2008-10-21 15:16:27 -0500 (Tue, 21 Oct 2008)

That was tough. I think I broke a sweat.

Re:Keyword: Herd

[jimdread]

I like to use git because I find it easy to make a branch for testing out some new code, and easy to merge the branch into the trunk if I want to keep it. Here are some aliases I wrote that cover pretty much all the git I use. If I decide to change version control systems, I can change the aliases. alias vca='git add .'; alias vcb='git branch'; alias vcc='git commit -a'; alias vcd='git diff'; alias vcm='git merge'; alias vco='git checkout';

As for choosing between git and subversion, why not try both? It's pretty unlikely that somebody will tell you what you like best. You have to find out for yourself. Considering that they are free software, easy to install, and pretty easy to use, you can try both and see if one of them seems better to you. I tried both, and I chose git. But I don't mind if other people use subversion, RCS, SCCS, or whatever they feel like using.

Subversion and git have different models. Subversion has a client-server model with the repository accessible by http. Git uses a distributed model, with each user getting their own copy of the repository, and the possibility of merging things from one repository to another. This might make git work better if the users' computers aren't always able to connect to a remote repository.

Try them both, see which one you prefer.