Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Programming IT Technology

Practical Reasons To Choose Git Or Subversion? 667

Posted by kdawson
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."
This discussion has been archived. No new comments can be posted.

Practical Reasons To Choose Git Or Subversion?

Comments Filter:
  • Blah (Score:5, Funny)

    by Anonymous Coward on Tuesday October 21, 2008 @02:14PM (#25457871)

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

  • Windows. (Score:5, Interesting)

    by scott_karana (841914) on Tuesday October 21, 2008 @02:17PM (#25457931)

    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. (Score:5, Funny)

      by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Tuesday October 21, 2008 @02:43PM (#25458393) Homepage Journal

      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. (Score:5, Interesting)

      by Cyberax (705495) on Tuesday October 21, 2008 @03:12PM (#25458935)

      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.

      • Re:Windows. (Score:5, Interesting)

        by Daniel Phillips (238627) on Tuesday October 21, 2008 @03:24PM (#25459147)

        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: (Score:3, Interesting)

      by mcvos (645701)

      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.

      Speed isn't the only factor when choosing a version control system (or even the most important one), but considering its lightning speed on unix-likes, I wouldn't be all that surprised if git's less-than-brilliant performance on Windows is still faster than SVN.

    • Re: (Score:3, Insightful)

      Another factor in a Windows-centric corporate environment, SVN will function very usefully without a server. While I would prefer to have a proper repository server, the IT departments of most of my clients simply refuse to support anything outside a small range of "corporate esentials". Since a SVN repository on a file share is better than no VCS, that's what ends up being used.

  • IDE Integration (Score:5, Interesting)

    by FortKnox (169099) * on Tuesday October 21, 2008 @02:17PM (#25457937) Homepage Journal
    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 (Score:5, Insightful)

      by Tester (591) <olivier.crete@[ ]ete.ca ['ocr' in gap]> on Tuesday October 21, 2008 @02:24PM (#25458077) Homepage

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

      • Re:IDE Integration (Score:5, Interesting)

        by dubl-u (51156) * <2523987012@pota . t o> on Tuesday October 21, 2008 @02:58PM (#25458713)

        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 (Score:5, Insightful)

          by Wonko (15033) <thehead@patshead.com> on Tuesday October 21, 2008 @03:10PM (#25458887) Homepage Journal

          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.

          • Re:IDE Integration (Score:5, Insightful)

            by dubl-u (51156) * <2523987012@pota . t o> on Tuesday October 21, 2008 @03:52PM (#25459647)

            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.

            • Re:IDE Integration (Score:4, Insightful)

              by Dhalka226 (559740) on Tuesday October 21, 2008 @04:17PM (#25460067)

              There are a lot of times I don't branch, but it's usually out of laziness and I end up regretting it at some point in the project.

              Easily, the most common reason for branching is a stable-versus-development split. I've run into it in virtually every project I've been on that involved any other people (even just as employer), and even a number of my personal projects. Stable branches almost always need an occasional bugfix or super-quick feature that I can be reasonably sure to get in in a one or two commits, and typically these things need to go out ASAP. I've run into that a million times with copy changes. In programming world, copy changes are usually the lowest possible priority thing, but with clients they're often some of the highest priority.

              Point being, if I'm ever working on adding some major feature--really anything that will take more than a couple days, and sometimes even when it won't--I'm likely going to be better served doing it in a branch. If it happens that I get through it without needing to make any changes to the stable code, sweet! The merge is going to be super quick and easy. If not I'm going to be very glad I took the time to branch or regret not having done so. "I can't make your change right now because I have a ton of half-finished in-development code" is not an excuse people are interested in hearing.

              • Re:IDE Integration (Score:4, Insightful)

                by dubl-u (51156) * <2523987012@pota . t o> on Tuesday October 21, 2008 @04:31PM (#25460339)

                Easily, the most common reason for branching is a stable-versus-development split.

                I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?

                I've run into that a million times with copy changes. In programming world, copy changes are usually the lowest possible priority thing, but with clients they're often some of the highest priority.

                Yes, you could solve the problem that way. I normally solve it by releasing frequently. It's pretty rare that people mind waiting a few days. Or if they need to change copy a lot, by putting the copy in a content management system, so they can change it whenever they get the urge.

                I can't make your change right now because I have a ton of half-finished in-development code

                I solve that by not having a ton of half-finished code. Ship early, ship often, I say.

                • Re: (Score:3, Insightful)

                  by SydShamino (547793)

                  I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?

                  When adding a new feature that might take 2-3 weeks to be "stable", do you use a different system to back up your work each day? Wouldn't it be easier to make a branch you could commit to back up to each day, then merge it in when your branch is stable?

                  • Re: (Score:3, Insightful)

                    by dubl-u (51156) *

                    When adding a new feature that might take 2-3 weeks to be "stable", do you use a different system to back up your work each day?

                    I don't check in things that I don't think are stable. I do that primarily through test-driven development and pair programming, plus automated acceptance testing and showing new versions to product management and/or QA every few hours.

                    Bugs only get harder to find over time. It seems a lot cheaper to me to kill them dead as soon as possible, rather than storing them up and trying to find them later.

                    • Re:IDE Integration (Score:5, Insightful)

                      by musicmaker (30469) on Tuesday October 21, 2008 @06:38PM (#25461825) Homepage

                      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.

                • Re: (Score:3, Insightful)

                  by honkycat (249849)

                  I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?

                  Yeah, and it'd also be nice if software was released without bugs. Every non-trivial change (and more trivial changes than you or I would like to think) introduces the chance for an unintended consequence. If you are attempting to ship a solid product and you need a critical bug fix ASAP, you really want to start from EXACTLY the code you shipped last time and make the minimum change to fix the critical bug.

                  For some, especially informal users, a frequent release schedule with lots of miscellaneous changes

                • Re: (Score:3, Insightful)

                  by pthisis (27352)

                  I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?

                  Not always.

                  In the real world, a development branch often requires coordination between multiple programmers; I change the broken API to FooLib. I know that this breaks the callers, but that's okay because we're working in the "big changes to FooLib" branch. I test that FooLib 2.0 works okay, then check it in to the dev branch. The rest of the team updates their code bases which use FooLib to

            • Re:IDE Integration (Score:4, Informative)

              by mcvos (645701) on Tuesday October 21, 2008 @04:25PM (#25460219)

              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.

              That may work fine when you're the only one working on the code, but if you're working with someone else, and he's committed code that you don't think is any good (or at least not ready for production yet), but later commits from you are, then with a single trunk you're simply out of luck.

              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.

              But what if you've been working on something that seemed like a good idea at the time, and suddenly you realise you're going completely in the wrong direction and need to undo a lot of commits (but you want to keep the other bugfixes you did)? Or what if someone else is working on the same project?

              Git makes these things pretty painless.

              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.

              No, it can't resolve your personal differences for you, but it can prevent others from polluting your codebase. It can make it easier to undo others' mistakes. Or your own.

              The whole point of branching is to increase complexity,

              Have you read what you just wrote here? Ofcourse the point of branching is not to increase complexity. It's to reduce it. The problem is that with many source control systems (like SVN) the subsequent merging is complex and often needs to by done by hand. With git, that's not the case.

              Despite what a lot of people say, it's actually not true that git makes branching and merging easy. It makes it unavoidable, trivial and painless. It's only in other systems where branching and merging adds complexity.

              That's not to say I never branch. But it's always a last resort for me,

              Well, with git, it needn't be the last resort. You'll be doing it every day without even noticing.

              • Re: (Score:3, Insightful)

                by dubl-u (51156) *

                That may work fine when you're the only one working on the code, but if you're working with someone else, and he's committed code that you don't think is any good (or at least not ready for production yet), but later commits from you are, then with a single trunk you're simply out of luck.

                This is back to my original point. If I'm working with people who are regularly checking in bad code, then I solve that by talking with the person. Why would I let him go on doing dumb things any longer than necessary?

                But what if you've been working on something that seemed like a good idea at the time, and suddenly you realise you're going completely in the wrong direction and need to undo a lot of commits (but you want to keep the other bugfixes you did)? Or what if someone else is working on the same project?

                I mainly solve this by making sure it doesn't happen much. Branching can only save you if you realize it's a bad idea before you merge to trunk, only if your changes are mostly bad. I think the solution to bad ideas is better product management, not better version control.

                Have you read what you just wrote here? Ofcourse the point of branching is not to increase complexity. It's to reduce it.

                Let's take a simple e

            • Re:IDE Integration (Score:5, Insightful)

              by Abcd1234 (188840) on Tuesday October 21, 2008 @04:31PM (#25460343) Homepage

              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?

        • Re: (Score:3, Insightful)

          by GooberToo (74388)

          Branching and merging is a fact of life. If you don't branch or merge, likely your project is either trivial or your pool of developers small. Larger projects with many developers require the ability to branch and merge large bodies of code. Attributing this fact to personalities is nothing but hand waving. Personality conflicts may be the root-cause for you but is not the root for the majority of people that require such functionality.

          Simple fact is, branching and merging is required for complex software d

        • Re:IDE Integration (Score:5, Informative)

          by Niten (201835) on Tuesday October 21, 2008 @03:40PM (#25459471)

          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: (Score:3, Interesting)

            by skeeto (1138903)

            but it doesn't mean much when SVN's handling of merges is so primitive.

            Precisely. I like this think of it this way: Einstein said "Make everything as simple as possible, but not simpler." When Subversion tried to be elegantly simple by having tagging and branching be exactly same operation as cheap copies, they went too simple.

    • by mangu (126918)

      most of the items that git 'claims' to be better on is something IDE plugins fix

      Funny, but I've never got the IDE plugin for *any* version control system working well. Since I always have at least one command window open, typing "git commit -a" is faster and easier than locating the corresponding menu, clicking on it, and praying that it will do exactly what I want.

      Disclaimer: Of course, this doesn't mean I don't use the many other functions that work better on an IDE than in a text command. I can use vi o

      • Re: (Score:3, Insightful)

        by Cyberax (705495)

        For example, my IDE (IntelliJ IDEA) allows me to view history for a _selected_ _class_ or even a piece of code. Even across branches and merges.

        Try to do it from a command line (you can, but you'll need a lot of 'blame' and 'log' commands).

    • Re:IDE Integration (Score:5, Insightful)

      by Haeleth (414428) on Tuesday October 21, 2008 @03:02PM (#25458779) Journal

      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.

      • Re: (Score:3, Funny)

        by PinkPanther (42194)

        which is the most mature, most stable, and most flexible one in widespread use: Unix.

        Yes, but unfortunately for you the kids aren't traipsing on your lawn these days.

  • by Bromskloss (750445) <auxiliary.addres ... acy@gmail . c om> on Tuesday October 21, 2008 @02:17PM (#25457941)

    They are both of the "distributed" kind.

    • Re: (Score:3, Informative)

      by Dr_Barnowl (709838)

      This thread is prompting me to have another go with git on Windows ; I've been using Bazaar for my project (both the source for the project, and the version control for the actual content of the project).

      The performance on Windows has come along in leaps and bounds since v 0.9 - it started off just "a lot faster than Subversion", it's got to the point where it's "wheee, that's fast".

      Of course, you try out the same file tree with Bazaar on Linux and the speed makes you a little green with envy...

      Bazaar isn't

  • Familiarity? (Score:5, Insightful)

    by gorrepati (866378) on Tuesday October 21, 2008 @02:18PM (#25457953) Homepage
    Thats all there is it to it, oh mighty one!
  • my choice (Score:5, Informative)

    by liquidpele (663430) on Tuesday October 21, 2008 @02:19PM (#25457973) Journal
    I went with subversion because our programmers are mostly just website guys, and it had the most user friendly tools (for windows and mac) and was the easiest for them to learn.

    I also like the central server aspect, so that there is one place where the code is located, and I just have to keep that backed up. Yea, I know GIT is distributed, but it's easier to manage subversion with the one main server.

    Just my $0.02
    • Re:my choice (Score:4, Insightful)

      by sohp (22984) <snewton @ i o . c om> on Tuesday October 21, 2008 @02:26PM (#25458109) Homepage

      I also like the central server aspect, so that there is one place where the code is located, and I just have to keep that backed up.

      Nothing wrong with that, if it's effective for you and your team, and clearly svn wins out over git. Trying to make git within that model is just adding complexity without getting the benefits. If, in the future, you and your team decide you need to change how you do source control, then git, or some other distribute peer-to-peer system, might be the solution. But don't just use it as a drop-in replacement for centralized server development.

      • Re:my choice (Score:4, Interesting)

        by onefriedrice (1171917) on Tuesday October 21, 2008 @02:49PM (#25458511)

        But don't just use it as a drop-in replacement for centralized server development.

        I disagree. You can take advantage of git's other positive aspects even if you manage a central repository: Common operations are speedy, local branching, and easy merges are all benefits you get by using git regardless of whether you take advantage of the distributed nature of git or not.

        I won't go so far as to say that all other SCM is total crap, but having recently switched my code repositories to centralized git repositories, I certainly wouldn't go back or put a new project in anything else. It was so easy converting my previous repositories to git (preserving history) that I think many people can and should consider git as a "drop-in replacement" for other SCM.

        The only reason I can think of to not go with git is (like the OP pointed out) the lack of nice UI tools (and premature Windows support). I can totally understand how this may be a show-stopper for many groups and projects, and that's fine. But to those groups or individuals not on Windows who aren't afraid of a few easy command-line programs, do yourself a favor and switch to git. Really, it's that much nicer.

        • Re: (Score:3, Insightful)

          by Otto (17870)

          I'm not afraid of the command line, but I'll be damned if I'm going back to IDE-less development for any project more complex than a simple webapp.

          I don't use Windows for development, but I DO need my IDEs.

          Git fails because of the lack of integration. Until it has that, it does not fit my needs. What's more, it fails to start with because they didn't consider that in the first place. A "simple text editor" dev environment stopped being useful or productive back in the 90s.

      • Re:my choice (Score:4, Interesting)

        by mcvos (645701) on Tuesday October 21, 2008 @04:56PM (#25460697)

        I also like the central server aspect, so that there is one place where the code is located, and I just have to keep that backed up.

        Nothing wrong with that, if it's effective for you and your team, and clearly svn wins out over git. Trying to make git within that model is just adding complexity without getting the benefits.

        Not true. I hadn't even heard of git one month ago, but we just set up a central repository system. Actually we already had a central git repository (on github) before I started working here, but that meant everybody pushed their commits into the same repository, which the guy responsible for deployment to production didn't like: he wanted to keep it stable and only accept changes he approved of.

        So now everybody has his own fork on github, pushes commits to his own fork, and the guy merges those forks (branches, basically) back into the main repo. Since merging is trivial, this works out very well. Everybody can access everybody's commits without messing with the stable trunk or making a big mess of things, because git does all the heavy lifting for us.

        Having used SVN before, I was very skeptical about git until less than a week ago. Now that I've seen what it can do, I'm a believer.

    • Re:my choice (Score:4, Informative)

      by Jason Earl (1894) on Tuesday October 21, 2008 @02:45PM (#25458437) Homepage Journal

      Precisely. I don't use Subversion for managing code anymore because for merging the distributed version control systems are much much better. However, Subversion is an excellent versioning file system, and that's what most people actually want. It handles large files well (try checking a 500M file into git, mercurial or bazaar sometime), and it can even be used as a WebDAV share for completely braindead use by normal end users. End users see the repository as a Network drive, but I can go back and get old revisions easily.

      Now that Subversion has more advanced merging abilities it might even be suitable for shops that like Subversions centralized nature but still need to merge on a regular basis.

      Besides, mercurial, git, and bazaar all interface well with Subversion. I frequently use bzr as a front end for subversion repositories if I know I am going to be doing any merging.

  • by oever (233119) on Tuesday October 21, 2008 @02:20PM (#25458005) Homepage

    Git is not well supported on Windows like Subversion is with turtoiseSVN. There is no good integration in Eclipse or Netbeans. The workflow is more complicated and enterprise tools such as Jira and Confluence do not support it.

    These things may improve but right now, Git is not very well suited for use in corporate environments.

  • by Anonymous Coward on Tuesday October 21, 2008 @02:22PM (#25458023)

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

    • Re: (Score:3, Funny)

      by Tumbleweed (3706) *

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

      Shut up, Palin.

  • not 1:1 (Score:5, Interesting)

    by sohp (22984) <snewton @ i o . c om> on Tuesday October 21, 2008 @02:22PM (#25458025) Homepage

    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.

    • Re: (Score:3, Informative)

      by Nevyn (5505) *

      Why, does that matter? Most of the git work I do there is a central repo. that everyone with privs pushes to. So instead of "svn commit" you have "git push" ... except with git you can create local branches, work disconnected, don't need to give commit privs. out as much, and it's much faster.

  • by David Gerard (12369) <slashdotNO@SPAMdavidgerard.co.uk> on Tuesday October 21, 2008 @02:22PM (#25458037) Homepage
    Real programmers type cat | cc and get it right the first time.
  • by vladd_rom (809133) on Tuesday October 21, 2008 @02:23PM (#25458057) Homepage
    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.
  • by MrFreezeBU (54843) on Tuesday October 21, 2008 @02:23PM (#25458061)
    How odd that I was just watching a talk that Linus gave at Google. Link to the talk [youtube.com]
  • Linus explains all (Score:4, Informative)

    by rehabdoll (221029) on Tuesday October 21, 2008 @02:25PM (#25458093) Homepage

    http://www.youtube.com/watch?v=4XpnKHJAok8 [youtube.com]

    He might not be very objective and his talk obviously only offers one side. Still, might be informative :)

  • Go with Bazaar (Score:5, Interesting)

    by bbn (172659) <baldur.norddahl@gmail.com> on Tuesday October 21, 2008 @02:27PM (#25458115)

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

  • by Ant P. (974313) on Tuesday October 21, 2008 @02:28PM (#25458131) Homepage

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

    • by ignavus (213578) on Tuesday October 21, 2008 @05:50PM (#25461319)

      My problem with CVS is that I keep confusing it with CSV.

      So when discussing file formats I can never remember which acronym I should be using, and keep referring to CSV data files as CVS. Age does that to you.

      Git, on the other hand, would distract me with thoughts of the "stupid gits" using it. And bzr just makes me think "bizarre".

      Mercurial sounds exotic, engimatic. Maybe I'll upgrade to that.

      Slashdot - where some stupid git will subvert the conversation by advising you to choose a SCM based on how bizarre the name is.

  • Git and SVN (Score:5, Informative)

    by MemoryDragon (544441) on Tuesday October 21, 2008 @02:29PM (#25458143)
    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)
  • similar thoughts (Score:3, Interesting)

    by Speare (84249) on Tuesday October 21, 2008 @02:29PM (#25458149) Homepage Journal

    I've been using CVS forever, mainly because it was the only real noncommercial option ten years ago. But I'm interested in trying out any versioning system that will work better, because I know I'm abusing CVS with my file storage needs.

    I do a fair amount of hobby coding, so any of the systems work well for that. Thousands of tiny text files are easy to merge. The sandboxes are fast and I can set up my repository on another machine on my lan.

    However, I also do a fair amount of semi-professional photography. My sandbox may have a couple thousand binary files that range anywhere from 2 MB to 2 GB. The number of versions of a file may typically go as far as 4 or 5, rarely as high as 10. A new version is best handled by simply snapshotting the whole new binary file, like the old VMS filesystem does. My repository on my lan machine has several tens of thousands of these binary files. My sandbox is rarely complete: I only sync certain subfolders now and then, and when I've checked in my changes and need space, I just erase that area of the sandbox. As long as I don't try to (cvs update -d) at the top level, I'm fine.

    I know I may be wrong, but if I switched to git or mercurial, as I understand it, every sandbox is/has its own repository with complete history, and these tools are more interested in how to merge changes from repository to repository. This is not what I want, in that the local sandbox+history would easily bloom into the many-gigabyte range and start to crowd my regular working space. I read a bit about their repository 'packing' options but that's not a solution, it's a maintenance feature.

  • by Anonymous Coward on Tuesday October 21, 2008 @02:31PM (#25458165)

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

  • Does it matter? (Score:5, Interesting)

    by Jeff Hornby (211519) <jthornby@sympaBO ... minus physicist> on Tuesday October 21, 2008 @02:32PM (#25458191) Homepage

    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.

  • by shellster_dude (1261444) on Tuesday October 21, 2008 @02:34PM (#25458235)
    Many of the things that Git touts as huge improvements over svn really don't apply to any collaborative work I have ever done. So what, I can show people my little version of the repo with out committing it? I can just send the source files to them out of my svn checkout. So what, I can stash stuff and come back to it later? I can branch and merge in svn. I can leave comments, like every good programmer should, so that I will know what was done on the branch, and the current status of the project at a glance. So what, I can check stuff out of and commit the source on my local system without network connections? I can make multiple copies of my version of the source code that I checked out of the svn repository. In either case, if you don't make sure you have the latest copy of the code, you are gonna have fun trying to merge it later. So what, Git will allow me to make patches so that I can show the changes to my coworkers? I could just as easily send them a diff of my copy and the svn repo.

    There is nothing wrong with git. I just don't see a clear advantage to it. In every argumentative paper I have seen about git vs svn, they always tout the above "advantages" of git. These items don't translate to actual advantages during project work, in my experience. If anything, the multiple local repositories all over the place, would seem to me, to cause more wasted time trying to merge in changes to the central repository, because of the local git repo's having a tendency to allow themselves to get so out of date.

    The main reason I use svn still, is because I learned it first, it does not have any disadvantages, for me, when I compare it to get, and it is well supported, and has a large developer base.
  • by m.dillon (147925) on Tuesday October 21, 2008 @02:45PM (#25458439) Homepage

    The DragonFly project is planning on moving out of CVS and has been looking at various repositories. We aren't actually interested in Subversion per-say, not any more, but some of our developers have used GIT and a few are advocating for mercurial as well. We need to come to a decision by mid-november.

    I haven't used Mercurial yet myself. I have used GIT. It took about a week to get used to it but once I understood the contextual labels things became a lot more obvious. We will maintain our central repository either by having it pull from the individual developer's repositories or by having the developers push into it. I'm still not quite sure what the best methodology is. It has to be automated no matter what.

    If someone is using GIT in a similar manner I would like to hear your story.

    I would also like to solicit opinions from people on GIT vs Mercurial.

    -Matt

  • mercurial (Score:3, Interesting)

    by BountyX (1227176) on Tuesday October 21, 2008 @02:58PM (#25458711)
    How about HG (mercurial)? It offers the best of both worlds supporting excellent windows integration (TortoiseHg, Eclipse plugins, etc) and having a large subset of similar features compared to git.
  • by ChrisA90278 (905188) on Tuesday October 21, 2008 @03:49PM (#25459587)

    What size is your project? For small projects with one to three people who all work in the same place yu can use RCS. It is serverless and works inside the file system. For many years I simply NFS mounted the RCS directories onto the development machine. There is almost zero setup and very little learning curve.

    CVS was a server centric RCS. If you don't need a server because you are the only developer on the project RCS is everything you need

    I also use RCS for all those small 8.conf file in /etc. just do a "mkdir /etc/RCS" and you are setup and running. It's that easy.

  • They don't exist (Score:3, Insightful)

    by OrangeTide (124937) on Tuesday October 21, 2008 @04:16PM (#25460059) Homepage Journal

    There is no such thing as a "die hard" subversion fan. People use subversion because they already use subversion. Not because they are fanatical about their choice. Which sets them apart from people who go for Git, Mercurial, etc. it puts subversion people roughly in the same group as CVS people.

    It's hard to be fanatical about the philosophy of "if it ain't broke, don't fix it"

  • Easy (Score:4, Interesting)

    by lewp (95638) on Tuesday October 21, 2008 @04:46PM (#25460565) Journal

    Git vs. SVN is more of a philosophical argument than a technical one. Git encourages disconnected operation and independent work more, while SVN tends to pay off the most if you're working regularly in lockstep with your team and everybody has a clear picture of what everybody else is doing. Not that you can't work on one kind of project with the other software, but it's more painful.

    There are bona fide technical issues you'll probably encounter no matter which one you pick, but those issues are trivial compared to the productivity you'll gain/lose by choosing the right one for your project and your (team's?) way of working.

    For you specifically, since you work with Rails, use Git. Everybody else is now, so it'll make dealing with other Rails developers easier. Most of the junior Rails folks we looked at recently (and haven't hired) are familiar with Git but not SVN.

    For everybody else, if you're a solo/freelance developer working by yourself, the choice doesn't matter at all. You don't really run into the major differences between the two until you start collaborating with other people.

  • by Xua (249955) <gshimansky AT mail DOT ru> on Tuesday October 21, 2008 @05:18PM (#25460907)

    We've been through CVS, SVN and finally GIT when developing our code internally for a big open source project before opening it.

    Git actually requires changing the mindset for developers from producing the code to producing the patches.

    This is an excellent description from one of my colleagues and I think that Git is ideally made for making patches. Patches are what are valued and needed in the open source world while it is still often different for the corporate inner projects.

    When we were going to open source the code and understood that we'll have to behave like it is done in the open source, send patches to committers, Git became a natural choice although the central repository of the project is in SVN (Apache repository). Developing patches is different from developing the code in a small sized team. Git offers absolutely the greatest power to operate with code changes (patches) locally than any revision control that I've seen.

    The article misses a tremendously useful feature of Git called "rebase". It is useful when you develop some changes against a trunk that changes while you work on your code locally. You make some local commits and to make them synchronized with the current state of trunk it is necessary to rebase them on the new version. Git does it by far in the most convenient way I've seen applying all of your local commits one by one and asking to resolve conflicts when it is necessary. Of course it requires some discipline to commit locally in small portions, but it is easier than "merging often" with the trunk of development than subversion handbook says. Merging is often tedious and it is way easier to just commit small changes to a local repository than every time resolve the same conflicts when "merging often". You never have to resolve a conflict again after you've done rebase with Git.

    I didn't find performace on windows so bad. Cygwin port works ok, not so fast as on Linux, but it is good enough compared to subversion update. TortoiseSVN has to keep a separate cache to make windows performance decent. This cache is sometimes renewed and slows down a system for a long time if your checked out repository is big enough. All of subversion transactions like "svn log" require server interaction while Git is lightning fast. So I think even if filesytem performance of Git to clone or checkout may not be so good on Linux it is compensated with no delay to do every day commands like log, annotate, diff, etc.

Excessive login or logout messages are a sure sign of senility.

Working...