Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Programming IT Technology

Practical Reasons To Choose Git Or Subversion? 667

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:
  • go with Perforce (Score:2, Informative)

    by flannelboy ( 344272 ) on Tuesday October 21, 2008 @03:19PM (#25457965) Homepage

    Seriously. I know it's $800 a user, or something like that, but it's worth every penny. (Yeah, yeah, it's closed source, and ships as a binary, but it _really_ works).

    Note that Perforce is free for open source projects.

  • my choice (Score:5, Informative)

    by liquidpele ( 663430 ) on Tuesday October 21, 2008 @03: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
  • by vladd_rom ( 809133 ) on Tuesday October 21, 2008 @03: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 @03:23PM (#25458061)
    How odd that I was just watching a talk that Linus gave at Google. Link to the talk []
  • Linus explains all (Score:4, Informative)

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

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

  • Git and SVN (Score:5, Informative)

    by MemoryDragon ( 544441 ) on Tuesday October 21, 2008 @03: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)
  • by Anonymous Coward on Tuesday October 21, 2008 @03: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...

  • by MemoryDragon ( 544441 ) on Tuesday October 21, 2008 @03:31PM (#25458173)
    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!
  • by doug ( 926 ) on Tuesday October 21, 2008 @03:33PM (#25458205)

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

  • What about Hg, then? (Score:1, Informative)

    by Anonymous Coward on Tuesday October 21, 2008 @03:34PM (#25458225)

    Mercurial is something of a halfway point between the ease of Subversion and the power of Git, with the added advantage that it works well on Windows and has both GUI wrappers and IDE integration.

    I use Git over Hg primarily because I *do* use the command line for everything (and Git's CLI is nothing short of excellent), but Subversion is just painful with any amount of wrapping.

  • by Yokaze ( 70883 ) on Tuesday October 21, 2008 @03:41PM (#25458347)

    The other dvcs Mercurial: Tortoise [], Eclipse [], Netbeans []
    I don't see, why the workflow has to become more complicated for server-side things like Jira and Confluence: you simply create a automatic server-side conversion from your central dvcs repository to a svn repository for those tools are done with it.

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

    by Jason Earl ( 1894 ) on Tuesday October 21, 2008 @03: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 mangu ( 126918 ) on Tuesday October 21, 2008 @03:45PM (#25458443)

    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 occasionally for a quick edit, but development of a large code base is much easier and quicker on a good IDE. It's just that version control is quicker on the command line.

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

    by trjonescp ( 954259 ) on Tuesday October 21, 2008 @03:53PM (#25458589) Homepage

    Unless you are coding in something like vi or emacs, I don't use the command line for my source control.

    I use emacs and never have to use the command line either. emacs is an IDE just like any other. It's just not graphical.

  • Re:go with Perforce (Score:3, Informative)

    by liquidpele ( 663430 ) on Tuesday October 21, 2008 @04:04PM (#25458791) Journal

    What I couldn't believe is that subversion couldn't track branch points. The end-user had to manually 'remember' which revision of each file was branched from to aid in merging later.

    Added in subversion 1.5

  • by CaptSaltyJack ( 1275472 ) on Tuesday October 21, 2008 @04:20PM (#25459067)

    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: []
    Repository Root: []
    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.

  • by MemoryDragon ( 544441 ) on Tuesday October 21, 2008 @04:30PM (#25459265)

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

    Resolved since SVN 1.5, merge tracking has been added!

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

    If you are in windows there isn't really much to compare: Mercurial simply works much better, has a much more active devel list (windows issues seem to be at the top of this list in getting solved quickest, windows support just happens) and is faster. On the other hand Git is buggy, has rather inactive windows development, poor integration into other windows applications and seems to have little support.

    On the *nix side of things, GIT and Hg are roughly equal (maybe with a slight speed and file size advantage to GIT). GIT does support more scenarios (like having an SVN server with GIT clients, something being actively worked on in Hg), but most of these are rather obscure.

    The mercurial nomenclature is much more similar to what you get in CVS/SVN than GIT is (though if you are looking for that, Bzr is much better still as by default it works just like SVN except that you cannot commit to a non-head revision). This means that the learning curve is smaller for Hg than for GIT (for example there aren't contextual labels in Hg, I didn't get that at first when I was using GIT either).


    As far as I am concerned that means Hg wins.

    But if you are simply looking to jump on the bandwagon of DVCSs, Bzr is actually what you should probably look for. It offers the speed advantages of a DVCS (and many of the other advantages like everybody gets a backup), yet doesn't require you to really learn anything new. It is only when you are looking to embrace the distributed aspect where GIT and Hg shine.

    Note that this should not discourage you from learning how to use both (and trying to actively encourage GIT on windows development). Competition here is good and makes both projects better.

  • Re:flamebait (Score:0, Informative)

    by Anonymous Coward on Tuesday October 21, 2008 @04:39PM (#25459457)

    Hey, just be glad it's tech related and somewhat interesting. If I see another slashvertisement, "OMG! copyrights are teh evil!1" or "Big brother is coming!1" story, I'm going to puke.

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

    by Niten ( 201835 ) on Tuesday October 21, 2008 @04: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:Windows. (Score:1, Informative)

    by Anonymous Coward on Tuesday October 21, 2008 @04:45PM (#25459533)

    Also, most .NET developers work on Windows with Visual Studio. Subversion has more traction on that platform, there's TortoiseSVN that integrates Subversion in Explorer and AnkhSVN that integrates Subversion with Visual Studio. I have looked at Git, but I'm very happy with these tools, and they are essential for getting others on the team to use source control at all.

  • by CarpetShark ( 865376 ) on Tuesday October 21, 2008 @04:47PM (#25459557)

    Git, Bazaar, Mercurial, Darcs and a few other distributed systems are the only ones I've entertained since I lost interest in RCS/CVS years ago. No one in their right mind should be even thinking about so-called tools like SVN these days.

    Even just to keep my simple documents like lesson plans and tutorials up-to-date across a few machines and platforms I don't control (with pen drives/emails in-between), I need to use rsync-like tools that can cope with more than a single central repository, and sync in both directions. The days of big central mainframes which hold the One True Source Code Repo are long gone.

    So far, my thoughts are this:

    Bazaar( aka bzr, aka bazaar-ng until recently ): very nice, but a little flakey now and then.

    Git: seriously fast, powerful, but too complex for any project with lay-contributors and too easy to hose your work with

    Mercurial and Darcs: not much experience with them, but at least Mercurial's TortoiseHg option for windows seems ready to go, which is a huge win if you care about a cross-platform solution.

  • Re:not 1:1 (Score:3, Informative)

    by Nevyn ( 5505 ) * on Tuesday October 21, 2008 @04:50PM (#25459617) Homepage Journal

    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 Dr_Barnowl ( 709838 ) on Tuesday October 21, 2008 @05:21PM (#25460159)

    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 as "industrial" as git - in both ways. It may not perform quite as well, but it's also less rough around the edges and supports more workflows. And it has the tremendous advantage of being mostly written in Python, which means that hacking on it is a lot easier. If you have an itch, it's a lot easier to scratch it.

    I would have hated to try to teach the default porcelain in git to my (non techie) users.

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

    by Abcd1234 ( 188840 ) on Tuesday October 21, 2008 @05:22PM (#25460169) Homepage

    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.

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

    by mcvos ( 645701 ) on Tuesday October 21, 2008 @05: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.

  • by qualidafial ( 967876 ) on Tuesday October 21, 2008 @05:26PM (#25460225) Homepage

    • Subversion will use less space on indivual developer's computers disks.

    I've heard git is pretty bad about disk space, but Subversion is a bit ridiculous in it's own right. With SVN you are storing the working copy twice: once for the files you will work on, and again as a backup copy so svn can do diffs.

    In mercurial the repository is heavily compressed and revisions are stored as diffs (with occasional full copies) so this is a non-issue if you don't have a lot of binary data. If you're going to use that much disk space with svn, you may as well go with mercurial and have the entire repository history while you're at it.

    • Using a central server will give you an obvious place to go to for a system of record.

    You can synchronize on a central repository using git, mercurial or bazaar. The difference is that you have the choice of when to push your changes upstream, and you have the option to continue working and performing commits locally when you are offline.

    • Using a central server will let you check user ids based on an external authentication system to make sure you can blame the right person when they break the software.

    This is all possible with distributed repositories too.

    You don't use branching that much and can safely ignore the dumbest decision ever on the part of the subversion developers

    I'm not sure what the "dumbest decision" you're referring to is. But I don't blame you if you don't use branching with CVS or SVN--branching is easy, but merging branches is horrid. The is due mainly to the fact that neither CVS nor SVN knows when a particular commit represents a merge from another branch of development. So you have to either merge from the branch point, or research the commit history to determine when the last time the two branches were merged--otherwise you'll have a major mess on your hands trying to merge two branches with many duplicate changes.

    With a distributed VCS this is not a problem. git, mercurial and bazaar all keep track of how you merge different changesets together so that a merge only as complicated as the actual changes make it, not how complicated your VCS tool makes it.

    For example, let's say you release version 3.0 of your software. You tag the changeset as "v3.0" and continue on work for 3.1.

    hg tag v3.0

    Now suppose that a week later, a security flaw is discovered which must be patched immediately. You update your working copy to the "v3.0" tag, and start a branch "3.0_maintenance". You make the changes and commit them to the 3.0_maintenance branch.

    hg update -r v3.0
    hg branch 3.0_maintenance
    // make the required changes in code
    hg commit -m "Security fix see bug 19237"

    You want your ongoing development on 3.1 to include the bug fix you just committed to 3.0, so you switch back to the default branch, merge the changes from 3.0_maintenance, and commit.

    hg update -r default
    hg merge -r 3.0_maintenance
    hg commit -m "merge bugfix from 3.0_maintenance"

    Later, when another bug is discovered in 3.0, this same process will suffice to patch the 3.0_maintenance branch and to merge the change back into the default branch.

    hg update -r 3.0_maintenance
    // fix bug in code
    hg commit -m "FIXED: bug 20122"

    // merge bugfix into default branch
    hg update -r default
    hg merge -r 3.0_maintenance
    hg commit -m "Merge bugfix from 3.0_maintenance

    Mercurial (or git, or bazaar) kept track of not only the branch points but the merge points for you, which makes merging simple like it should be.

    Contrast this with CVS or SVN where you have to track dow

  • Re:flamebait (Score:4, Informative)

    by caluml ( 551744 ) <> on Tuesday October 21, 2008 @05:35PM (#25460405) Homepage
    Retch [].
  • Re:IDE Integration (Score:3, Informative)

    by dubl-u ( 51156 ) * <> on Tuesday October 21, 2008 @05:54PM (#25460671)

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

    Solution: stop checking in stuff that doesn't work. I do this through unit testing, acceptance testing, pair programming, working within a few paces of a product manager, and a few other practices.

    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.

    I don't have anything against local copies. It's kinda hard to change the code if you can't change the code.

    being able to revert a messed up piece of code is awfully handy

    True. I use an IDE with undo for small cases of this, and reversion to head for large versions. But I think a better solution is to find mistakes early, so that screwing up is easy to fix.

    This also facilitates easier code review

    This is true only if you're willing to pay the cost of slower code review. Longer feedback loops inevitably create greater waste than shorter ones.

    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.

    I have never seen that not be the road to maintenance hell. For the customized versions of products I've worked on, it's not like customers don't want all the bug fixes and new features that you're putting into the app. They do, just with their customizations. Trying to juggle all that through branching and merging seems like a lot more work than just making the software configurable, templatable, or customizable directly.

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

    I don't remember saying I've never seen the need for that. Perhaps you replied to the wrong post?

  • Re:Go with Bazaar (Score:2, Informative)

    by Quartz25 ( 1195075 ) on Tuesday October 21, 2008 @06:01PM (#25460749) Homepage
    I have to second this, I've used Git when working on OLPC [] and I've broken my repositories more times than I can count.

    Bazaar does not break.
  • Re:Windows. (Score:5, Informative)

    by bladesjester ( 774793 ) <slashdot AT jameshollingshead DOT com> on Tuesday October 21, 2008 @06:08PM (#25460815) Homepage Journal

    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.

  • Re:Real programmers (Score:2, Informative)

    by rikkitikki ( 91982 ) on Tuesday October 21, 2008 @06:48PM (#25461283)
    Gah, hate to reply to my own post, but I got it working:

    cat << eof | cc -x c -

    i picked 'eof' as the marker of my end of input.  you can pick whatever you like.

    the compiler needs to know what language it is compiling, thus -x c

    and finally tell the compiler to read from stdin with '-'
  • Re:my choice (Score:3, Informative)

    by jonabbey ( 2498 ) * <> on Tuesday October 21, 2008 @07:34PM (#25461797) Homepage

    Ugh. Subversion 1.5 has 'merge tracking', if you want to call it that, in the most primitive fashion imaginable. Subversion has no way of tracking merge history in its essential structure, and certainly no way to do anything between multiple repositories.

    With Git, it's all content addressable, so you have complete flexibility, no matter the order or sequencing of branches and merges, across any number of branches and/or repositories you care to have, foreign and domestic.

    I used Subversion for several years with a large project, and it was a lot better than when we were using CVS, and I was rather fond of it.

    But Git is *so* *much* *better* with regards to branching and merging that it's not even funny. Add in fantastic tools like 'git gui', 'gitk', 'gitweb', and public project hosting sites like, and there's no contest.

  • by Dr_Barnowl ( 709838 ) on Tuesday October 21, 2008 @07:52PM (#25461987)

    Bazaar will let you work as if it were Subversion, for example, with a central server, lightweight local checkouts (with no history).

    It will also let the same group of people work offline. Or heavyweight checkouts that can be offline, but commit to the server by default.

    See here [] for more about workflows from the simple to the involved.

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

    by SanityInAnarchy ( 655584 ) <> on Tuesday October 21, 2008 @09:34PM (#25462989) Journal

    SVN isn't better or worse than GIT, except perhaps when examining a given feature.

    There are a very small number of features for which SVN is better than GIT.

    Therefore, even when working in such a way that SVN would suit you fine, I'd go with Git for things like size and speed alone.

    An SVN checkout of a single branch of my project (trunk, say) is a little over 160 megs. A git-svn checkout of the entire project -- all history it could find, all branches, all tags (and we tag once per deploy, which can be several times per week) -- is 140 megs.

    Given that, why would I waste my time with SVN? What does it do better?

    From what I can tell, there's partial checkouts -- which still have a fair chance of using more disk than a simple git clone -- and Tortoise. And there are things gitk does better than Tortoise, because of fundamental features missing from SVN.

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

    by dmuir ( 964412 ) on Tuesday October 21, 2008 @09:44PM (#25463083)
    I think you miss the point. In Git (and Bazaar), you're working with your own branches locally. You don't have to tell anyone that you've made them. Once you're happy with your experimentations in one branch and want to merge it into the "trunk", you can then either tell your team leader, "Hey, I've finished this new feature, pull from me", or depending on your rights, push it straight into the main repository. That's the beauty of distributed SCM's. You're the only one who has to juggle those balls. If you're able to juggle 10, then fine. If you're like me and can only deal with 1 or 2, that's fine too. The point is, it's your own repository. You can make as many or few branches as you like and nobody has to know.
  • Re:IDE Integration (Score:3, Informative)

    by xero314 ( 722674 ) on Tuesday October 21, 2008 @10:49PM (#25463671)

    Simple fact is, branching and merging is required for complex software development.

    You are half right, branching (or tagging) is good practices for all software, regardless of complexity, but merging is only required if you branch in an overly complex way.

    Branch only stable code for releases and leave the mainline as the Latest and Greatest and you never ever have to merge, ever. Which is great because branching is easy, merging sucks.

  • by Anonymous Coward on Wednesday October 22, 2008 @06:38AM (#25466019)

    SVN might be too simple for what you need. On the other hand, GIT might be an overkill. Mercurial stands between the two in terms of features and learning curve. Mercurial has a few more commands than svn, but it's a whole lot more powerful.

    And keep in mind that branch management is a LOT easier on Mercurial than on svn.

    Reading up to chapter 8 in this book may help you decide :

  • by Anonymous Coward on Wednesday October 22, 2008 @09:18AM (#25467131)

    From the GIT web site:

    Java GIT/Eclipse GIT (repository) originated by Shawn Pearce is a Java GIT library and plugin for Eclipse IDE, in very early stages of development. The site no longer seems to have the plugin. Robin Rosenberg has recently been working on history and compare views for the plugin. David Watson contributed GUI for branch handling and commit. Progress is slow but steady. A EclipsePluginWishlist has been started as a roadmap of features. A page has been started to follow development: EclipsePlugin.

    Conclusion: Not ready for production. See you next year.

  • by Anonymous Coward on Wednesday October 22, 2008 @09:24AM (#25467217)
    Mercurial aka. hg [] is another distributed VCS/SCM. It has much in common with git (although git *might* be a little more kick-assier in places), but may come in handy as a better SVN replacement because it does work well on Windows, brings very nice Explorer integration through TortoiseHg and is supported by Trac, too, so your toolbox might look pretty much the same. Don't know about integration into Eclipse and others, though.
  • Re:my choice (Score:3, Informative)

    by PeterBrett ( 780946 ) on Saturday October 25, 2008 @03:46AM (#25507817) Homepage

    Um. In git's case, it makes a copy of the 500 MB file, and calculates its SHA1. And that's all it does.

    Oh, no, that's not all. Try *changing* said 500MB file, and watch the difference in backend repo size. :3

    Try git gc. It initially stores the repository unpacked as a speed optimisation, on the assumption that the latest commits are likely to be accessed frequently. When you run the garbage collection tool occasionally, it 'packs' the commits into delta-compressed files. Why not do it straight away? Because the packing is an expensive process, it defers carrying it out so that when you git commit it completes as fast as possible to allow you to get on with your work.

    I hope that explains the 'lack of performance' you perceive.

A verbal contract isn't worth the paper it's written on. -- Samuel Goldwyn