Slashdot Mirror

← Back to Stories (view on slashdot.org)

Practical Reasons To Choose Git Or Subversion?

Posted by kdawson on from the while-we're-at-it-do-you-like-vi-or-emacs dept.

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."

42 of 667 comments (clear)

  1. Blah by Anonymous Coward · · Score: 5, Funny

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

  2. Windows. by scott_karana · · Score: 5, Interesting

    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.

    1. Re:Windows. by Just+Some+Guy · · Score: 5, Funny

      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.

      --
      Dewey, what part of this looks like authorities should be involved?
    2. Re:Windows. by Cyberax · · Score: 4, Interesting

      I've migrated my projects to Mercurial and is actually FASTER than Subversion on Windows and Linux for commit/update/status/blame.

      Mercurial is slower than GIT on Linux, but I just don't care.

    3. Re:Windows. by Daniel+Phillips · · Score: 5, Interesting

      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.

      --
      Have you got your LWN subscription yet?
    4. Re:Windows. by ozamosi · · Score: 5, Funny

      Git could [..] buy you a girlfriend

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

    5. Re:Windows. by Rayban · · Score: 4, Funny

      Just be careful with the order of command-line args. You wouldn't want it to paint your girlfriend (or maybe you do?).

      --
      æeee!
    6. Re:Windows. by bladesjester · · Score: 4, Informative

      I'd just like to say that I *love* tortoise.

      I work primarily in Windows now, but I grew up using the command line and have a number of years of experience in unix and linux. Setting things up for subversion using the command line always saw me digging back through docs to remember how to do it because I don't have to do it every day.

      With Tortoise, a couple of clicks and it's done. It saves me time and sanity.

      --
      Everything I need to know I learned by killing smart people and eating their brains.
    7. Re:Windows. by syousef · · Score: 5, Funny

      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

      --
      These posts express my own personal views, not those of my employer
  3. IDE Integration by FortKnox · · Score: 5, Interesting

    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.

    --
    Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
    1. Re:IDE Integration by Tester · · Score: 4, Insightful

      Clearly, you've never used git to think that some UI can make subversion usable.. Try merging a reasonably-sized branch with subversion (and you'll fail and cry and ask why oh why you didnt use git).

    2. Re:IDE Integration by dubl-u · · Score: 5, Interesting

      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.

    3. Re:IDE Integration by Haeleth · · Score: 4, Insightful

      I don't use the command line for my source control. IDE Integration means a lot...

      You feel free to wait around for "integration". The command-line client is already nicely integrated into my IDE, which is the most mature, most stable, and most flexible one in widespread use: Unix.

    4. Re:IDE Integration by Wonko · · Score: 4, Insightful

      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 constantly branch and merge even when I am the only one working on a codebase. When branching and merging are so easy why wouldn't you take advantage of it? Of course, it is always possible that I have a dysfunctional relation with myself.

      That's not to say git isn't awesome for certain situations, mind you.

      I can't speak for how awesome git is, I've never used it.

      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.

      If branching is increasing your workload instead of making things easier you are most likely not using a source control system that is good at branching and merging.

    5. Re:IDE Integration by Niten · · Score: 5, Informative

      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 =)

    6. Re:IDE Integration by dubl-u · · Score: 4, Insightful

      I constantly branch and merge even when I am the only one working on a codebase. When branching and merging are so easy why wouldn't you take advantage of it?

      I do, too. I call it "checking out" and "committing". I do it every few hours.

      If branching is increasing your workload instead of making things easier you are most likely not using a source control system that is good at branching and merging.

      When I'm building a unified product, what need would I have of branching and merging? If I'm not sure if something is a good enough idea to build, I don't build it. Or I build a quick, throw-away implementation to check an idea out. And then I throw it away.

      No matter how good a source control system is at branching and merging, it can't solve the real cost: maintaining a understanding of different, semi-incongruent notions of the project, and then resolving those differences. The whole point of branching is to increase complexity, and excess complexity is the enemy of every good software project. As Occam's razor says, you shouldn't multiply entities beyond that which is strictly necessary.

      That's not to say I never branch. But it's always a last resort for me, no matter how awesome the source control system is.

    7. Re:IDE Integration by Abcd1234 · · Score: 4, Informative

      It's because people have trouble forming teams and maintaining strong relationships in large groups.

      No, it's because:

      1) Software companies often need to create large, new features, and don't wish to destabilize the core product.

      2) Or it's because it's *far* easier for developers to be able to branch pieces of code, work on feature or bugfix development in their own little playpen with all the SCM bells and whistles (being able to revert a messed up piece of code is awfully handy, even if you're the only one working on the codebase), and then merge those changes when they're ready. This also facilitates easier code review (just check out the branch) and change control as a nice added bonus.

      3) Or because, in a more contract-oriented world, they might need to build customized applications for customers, and branch-and-merge strategies make that kind of code management possible.

      Honestly, if you've never seen the need to branch-and-merge, you've never worked on a large project. Period.

    8. Re:IDE Integration by Abcd1234 · · Score: 4, Insightful

      When I'm building a unified product, what need would I have of branching and merging? If I'm not sure if something is a good enough idea to build, I don't build it. Or I build a quick, throw-away implementation to check an idea out. And then I throw it away.

      So you've never implemented something and then wished you could revert a change that didn't work out? Or have never wanted to incrementally implement something without incorporating it into the final product until it was fully complete? Really?

    9. Re:IDE Integration by ShieldW0lf · · Score: 4, Interesting

      Looks like the reason he likes Git is because he's used to thinking of the other people he develops with as idiots, and it makes it easy for him to deal with them.

      The talking down at you attitude is supporting evidence....

      --
      -1 Uncomfortable Truth
    10. Re:IDE Integration by musicmaker · · Score: 5, Insightful

      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.

      --
      Everyone is living in a personal delusion, just some are more delusional than others.
  4. What about Git vs. Bazaar? by Bromskloss · · Score: 4, Interesting

    They are both of the "distributed" kind.

    --
    Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
  5. Familiarity? by gorrepati · · Score: 5, Insightful

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

    --
    You will never have experience until after you needed it.
  6. Comment removed by account_deleted · · Score: 5, Informative

    Comment removed based on user account deletion

  7. Neck and Neck by Anonymous Coward · · Score: 4, Funny

    I can honestly say that I have no preference of one over the other; having only just heard of them both by the OP.

  8. not 1:1 by sohp · · Score: 5, Interesting

    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.

  9. Real programmers by David+Gerard · · Score: 5, Funny

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

    --
    http://rocknerd.co.uk
    1. Re:Real programmers by Waffle+Iron · · Score: 5, Funny

      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

  10. Windows & Documentation by vladd_rom · · Score: 4, Informative

    Git wasn't really designed for Windows (where you lack the fork() call and must do everything using CreateProcess()-like API), and therefore the Cygwin port or the state-of-the-art in Git for Windows is horribly slow and inconvenient to use. Documentation is not optimal either; in some places you need to get accustomed with 2 or 3 different terms meaning the same thing, and often you must dig under the hood and learn how the underlying storage works in order to grasp the high-level functions (which doesn't happen in Mercurial's case, for example). For me the #1 blocker is the Windows thing because I'm not an idealist and I need to compromise, I suspect it's even more true in the corporate world.

  11. Linus on Git vs CVS/Subversion/Bitkeeper/etc by MrFreezeBU · · Score: 5, Informative

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

    1. Re:Linus on Git vs CVS/Subversion/Bitkeeper/etc by doug · · Score: 5, Informative

      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

  12. Go with Bazaar by bbn · · Score: 4, Interesting

    I found the Bazaar system to be superior to all other version control systems I have tried, including subversion and GIT.

    http://bazaar-vcs.org/

    Why? It is fast, it has tools integration and it can be used in much the same way as subversion/CVS. It is much easier to learn and just as powerful as something like GIT.

    There might be reasons to use GIT for extreme projects like the Linux kernel, but I believe Bazaar will do just fine for all reasonably sized projects.

  13. Re:go with Perforce by 32771 · · Score: 4, Insightful

    >Note that Perforce is free for open source projects.

    Yeah, so was BitKeeper and that used to really work too.

    --
    Je me souviens.
  14. Depends what you need more. by Ant+P. · · Score: 5, Funny

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

  15. Git and SVN by MemoryDragon · · Score: 5, Informative

    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)

  16. 3d party tools - Trac and Tortoise by Anonymous Coward · · Score: 5, Informative

    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...

  17. Re:CVS all the way baby by MemoryDragon · · Score: 4, Informative

    Sheesh tagging and branching really is the weak point of CVS while SVN does both pretty well! SVN just does it differently but unless CVS finally can make real tags or branches instead of doing full file copies I will stick to SVN. Sorry to say that CVS has some nice points, mostly being faster than SVN but thats basically it, everything else is way better done by SVN, especially tagging and branching! Git does both operations more along the lines of CVS with real tags and branches instead of hardlinking, but in the end the end result is the same, lightweight tags and branches, while CVS has heavyweight tags and branches!

  18. Does it matter? by Jeff+Hornby · · Score: 4, Interesting

    The truth is that despite the amount of invective on the subject, the choice of source control tools is not going to have any measurable impact on your project. Hell, most projects could easily run without a problem on a non-buggy version of MS-SourceSafe (if such an animal existed).

    The biggest cost you're going to have with your source control package is the initial setup. The biggest benefit you're going to get from your source control package is going to be minimizing that cost. Choose any of the modern source control packages and just get on with what you're being paid to do: write code.

    --
    Why doesn't Slashdot ever get slashdotted?
  19. Re:My own opinion (prob. very controversial) by Prien715 · · Score: 4, Insightful

    You've obviously never worked on a programming team.

    The best reason to use CVS or Git is the situation where multiple programmers are touching the same file(s) at once and you need to both commit. Also, the blame tool on SVN lets you easily tell when any given line of the code was added and why (see the commit message). The SVN repository I work on professionally has well over 25K commits...try managing that with a bunch of copies and text files!

    (I've done the versioned tarballs for a project I worked on alone...never again!)

    --
    -- Political fascism requires a Fuhrer.
  20. Re:My own opinion (prob. very controversial) by imbaczek · · Score: 4, Funny

    cp sucks at merging.

  21. Re:svn == unpleasant and maybe buggy by CaptSaltyJack · · Score: 5, Informative

    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.

  22. Re:I have considered Git but... by MemoryDragon · · Score: 4, Informative

    svn has no merge tracking. That's a pretty crucial feature.

    Resolved since SVN 1.5, merge tracking has been added!

  23. Re:Keyword: Herd by jimdread · · Score: 5, Insightful

    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.