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."
Windows. (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.
IDE Integration (Score:5, Interesting)
What about Git vs. Bazaar? (Score:5, Interesting)
They are both of the "distributed" kind.
not 1:1 (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.
Go with Bazaar (Score:5, 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/ [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.
similar thoughts (Score:3, Interesting)
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.
Re:Go with Bazaar (Score:1, Interesting)
I agree with you that bzr has most of the same features as git and a nice user interface.. And still, I don't think it matters. Every major open source project is switching to git. Because git is SUPER-fast (not just fast), and it has a greater mindshare and Linus is behind it. And the git user interface is being improved very fast, and its becoming more and more easy to use (without losing the power). I even heard Shuttleworth say that he would drop bzr completely when Gnome will to git (he said "if"..)
Does it matter? (Score:5, 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.
I have considered Git but... (Score:3, Interesting)
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.
Re:go with Perforce (Score:3, Interesting)
Ugh. I've used CVS, SVN, Perforce, Darcs, and Git over the years. Perforce was far and away the worst of the lot.
Whose bright idea was it to make the clientspec an unversioned artifact? In the company that I used Perforce at, which shall remain unnamed, it took me two weeks just to assemble a clientspec that would give a checked-out version of the repository that would actually build. Every developer in the place had their own personal flavor. What a ridiculous nightmare that was.
Git is far and away the best version control system I've ever used. Sure, it doesn't yet have decent IDE integration, but the command line interface is simple and gives you more power to rearrange your repository as needed than anything else I've seen. I love the fact that local development branches are so cheap; using independent branches for each of the features I'm working on at any given time helps make sure I don't let excessive coupling between subsystems creep in to my code, and merging (and rebasing, and rearranging commits) is faster and more painless than with any other system I've used.
Re:my choice (Score:4, Interesting)
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.
My own opinion (prob. very controversial) (Score:1, Interesting)
My own opinion is that version control systems are so mind-bogglingly difficult to use, I prefer to use a versioning file system and code packaged (occasionally) in tarballs. CVS/SVN are too clunky IMHO, and Git is only really usable if you happen to have a cloned version of Linus's brain nearby.
Thinking about it, a versioning file system has all the features I need (source code branching and merging? just use cp) but that's my own opinion. If you're desperate to use a VCS, are using *nix (Linux, OS X, Solaris, etc) and feel brave, give git a try - it's speedy and flexible (but still mind-boggling). For speed on Windows, Subversion's a better option.
Re:go with Perforce (Score:1, Interesting)
Whose bright idea was it to make the clientspec an unversioned artifact? In the company that I used Perforce at, which shall remain unnamed, it took me two weeks just to assemble a clientspec that would give a checked-out version of the repository that would actually build. Every developer in the place had their own personal flavor. What a ridiculous nightmare that was.
To be fair to perforce, I have used it at various different companies, source tree sizes, etc. and I have no idea what you are talking about.
Making a client spec is super easy. Type "p4 client" and map the revision control directory to somewhere on your local machine.
So your previous company may have done something foolish that you are now blaming on Perforce.
I've worked with 5,000,000 line source trees in perforce and it is extraordinarily fast. It integrates to virtually every IDE and Editor out there, and it has a fantastic command line if that is your tool of choice.
It works on many many platforms, including the usuals (Window$, Linux, Solaris, Mac OS X, BSD, etc.)
Perforce's strength is that it makes it really easy to branch and then merge.
So if you work with a lot of developers, and you need to do parallel projects, Perforce is incredible at this.
It's definitely worth a look.
Well (Score:1, Interesting)
Reasons to NOT choose a DVC over another DVC:
Baazar: Is really slow for big projects.
Git: Very, very, very fast, but it sucks on Windows.
Mercurial: Slower than Git.
Now, use Subversion if you need a restrictive control system (permissions, etc.)
mercurial (Score:3, Interesting)
Re:IDE Integration (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.
Git makes backups easy (Score:2, Interesting)
My biggest reason for switching to Git was that it makes backing up repositories vastly simpler.
In subversion I had to set up a repository with svnsync, and that repository couldn't be used interchangably with the original. And I would constantly have to go in and figure out how to unlock the destination repo. Lots of problems.
With git, I just clone the original repository and do a pull once in a while. And if I want, I can easily switch my clients to use the alternate repository (e.g., if a server goes offline).
I've been using msysgit for months and have had no issues with it. I don't quite understand the argument that 'git is terrible on windows'.
Re:Windows. (Score:5, 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.
Re:Windows. (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.
Re:My own opinion (prob. very controversial) (Score:4, Interesting)
You can leave comments on snapshots with versioning filesystems? I'm asking, I really don't know, haven't ever dealt with them, but any version control system that doesn't have comments is nearly worthless to me. I really need to know why my developers make a change as looking at the code for a bunch of changes across several files does not always result in the clearest picture of a change if you don't have some idea of what the goal was.
The commit comment log is priceless to me, but then again, the developers I work with are pretty good about making small changes and committing often with useful and informative comments. We try to avoid large commits that change lots of files, and when we have them, we generally warn everyone in advance that its coming and to be prepared for it so as to make merging things together a little easier. If everyone knows its coming, they tend to work together to make the merge smoother and make sure things work well together.
Re:Windows. (Score:3, 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.
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:IDE Integration (Score:3, Interesting)
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.
Re:Exactly. Use a solution for modern problems (Score:4, Interesting)
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.
Well, there is one big advantage to SVN: it's possible for mere mortals to understand how it works. To understand git you have to be a fucking genius.
But the awesome magic that git does makes git a worthwhile investment.
Easy (Score:4, Interesting)
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.
Re:my choice (Score:4, Interesting)
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:3, Interesting)
So as a cmd-line user who only uses centralized repositories (with only a couple of other developers), what kind of benefits would git provide over subversion?
Git would allow you to revert individual commits by other developers. That's something SVN will never be able to do. We just implemented a setup where each developer has his own repository on github, forked from the main repository on github. This makes it very easy for the guy with the final responsibility for deployment to decide which code he accepts and which he doesn't, while everybody else can easily accept whichever commits they like.
This is really useful when some people are committing crazy shit, or some people are working on a big new feature that shouldn't go live yet, while others are working on bugfixes that should go live as soon as possible.
Doing this with SVN is bloody hard. With git it's trivial.
Re:IDE Integration (Score:5, 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....
GIT is great, but it requires learning (Score:3, Interesting)
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.
Re:go with Perforce (Score:3, Interesting)
The only thing distinguishing the commercial VCS tools now is their integration with the likes of project management and issue tracking tools, and possibly the ease of getting a support contract (for those organisations that just have to have someone to blame).
None of them can compete with the next-gen DVCS systems in terms of performance ; Linus Torvalds notes that BitKeeper used to take about 10-15 seconds to merge an emailed patch to the Linux kernel, an "order or two" of magnitude faster than anything else available at the time. He thought it would be good to cut that down to 3 seconds ; when he had finished, he had git merging over 6 patches per second.
Why go through all the rigmarole of proving you are an open-source project (or squeezing $800 per seat out of accounting) when you can install git (or bzr, or hg) and
git init
git add .
git commit
You're off.
Re:IDE Integration (Score:3, Interesting)
In our office, we use Subversion, PHPUnit, Selenium, Xinc and Phing.
Every developer has their own subdomain and associated folder on the LAMP server, and we each check out from the trunk into our web root. We work on our own tasks on our own copy of the web application through sftp or sshfs, and whenever we have a particular piece of work done or a particular bug fixed, we check our work back into Subversion, which immediately kicks off a suite of Selenium tests that takes a couple of hours to finish and emails the whole team a report. If there is already a test suite running, it re-runs the suite again immediately once it's concluded and sends another email.
New versions of the software mean a brand new repository, and the only time we branch is when we want to create a snapshot that we allow clients using the older version to preview and test for usability (as opposed to functionality).
It works well for us.
Why Git is "hard to understand" (Score:1, Interesting)
Git is easy to understand if you don't pretend its svn. People who work for me that didn't use SCMs before pick up on Git naturally and with ease. People coming from cvs/svn (like myself) had a harder time. At the bottom of understanding git is just having at least the slightest inkling of how it works, and that it is nothing like svn or cvs. Git is much more like having your own snapshotting file system per-project directory, and you do searches through your snapshots to look at the history of various strings and files. Git's initial implementation never even maintained per-file information of any sort (except the file content during a snapshot).
My advice is use git, it will get fast on Windows (and currently isn't all that slow), and Mercurial is descent, but it doesn't do branching as well as git (try deleting branches) and _is_ slower where it counts. Seeing as git will get fast, and your repo history is going to stick around for a while, the transient state of git's performance in Windows shouldn't concern you that much.
Mercurial is noticeably slower when doing recursive diff between repo versions, it is noticeably slower when doing merges. Initial checkin and checkout are file copies, so its no surprise that mercurial and git (and any descent source system) will go at roughly the same speed, but these benchmarks are useless to you (who cares how fast you can do a 'cp'?).
See:
http://www.infoq.com/articles/dvcs-guide#sectionbench
In addition, not that you care now, but git's design is more likely to get file system support at some time, given how it works compared to mercurial (as I said, git behaves like a snapshotting file store).
Comment removed (Score:3, Interesting)
Re:Windows. (Score:3, Interesting)
I really like that it doesn't commit everything unless you explicitly tell it to - I've been bitten by that far too many times with Subversion.
Re:Windows. (Score:3, Interesting)
Git is an excellent piece of software, but Windows performance is not so great.
That's a bit of a myth. Windows Git is slower than Git on Liunx (since that was its native platform). However, I found it to be far faster than SourceSafe on the same machine.
If you think about it, there's really no way SourceSafe could even hope to compete, really. Even if it were the best-written code in the world (30 second pause while I try to stop laughing), SourceSafe has to go out to the network every time you want to do anything with a file. The same with CVS, SVN, etc. (unless your repository isn't shared). Git users only need the network for the initial pulldown and the occasional merge back up.
The original sources for the "Windows Git is slow" comments were Linux developers who were used to Git on Linux, not Windows developers who are used to other source control software on Windows.