Slashdot Mirror
Practical Reasons To Choose Git Or Subversion?
markmcb writes "I develop Rails applications and recently followed my lemming herd and made the switch to Git after learning some of the practical advantages Git offers over Subversion. As I'm sure there are many die-hard Subversion fans in the Slashdot audience, I'm curious what your key reasons are for sticking with Subversion. If possible, I'd like reasons that apply to 'most of the time' as opposed to arguments based on obscure features that may get used only a few times ever."
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.
Like the bi-line suggests... Unless you are coding in something like vi or emacs, I don't use the command line for my source control. IDE Integration means a lot... most of the items that git 'claims' to be better on is something IDE plugins fix. So the maturity of the plugin and the comfort with using it is a big thing for me. As such, I'm usually using CVS or Subversion.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
They are both of the "distributed" kind.
Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
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.
I found the Bazaar system to be superior to all other version control systems I have tried, including subversion and GIT.
http://bazaar-vcs.org/
Why? It is fast, it has tools integration and it can be used in much the same way as subversion/CVS. It is much easier to learn and just as powerful as something like GIT.
There might be reasons to use GIT for extreme projects like the Linux kernel, but I believe Bazaar will do just fine for all reasonably sized projects.
The truth is that despite the amount of invective on the subject, the choice of source control tools is not going to have any measurable impact on your project. Hell, most projects could easily run without a problem on a non-buggy version of MS-SourceSafe (if such an animal existed).
The biggest cost you're going to have with your source control package is the initial setup. The biggest benefit you're going to get from your source control package is going to be minimizing that cost. Choose any of the modern source control packages and just get on with what you're being paid to do: write code.
Why doesn't Slashdot ever get slashdotted?
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.
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.
This author takes full ownership and responsibility for the unpopular opinions outlined above.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
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.
Game... blouses.
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.
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.