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.
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.
[
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.
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.
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.
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.
Those using pirated Tinysoft signatures(TM) are a real threat to society and should all be thrown in jail.
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.
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.)
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.
Trying to install linux on my microwave, but keep getting a kernel panic...
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'.
Duct tape, XML, democracy: Not doing the job? Use more.
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.
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.
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.
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.
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).
That's a very good point that also applies to bzr.
(I personnaly use bzr and I've never used git but I think that most bzr functionnalities are available in git).
I use bzr over svn because when I start a project, I don't have to create (or have) a server, I don't have to make a complicated import. I just go in the folder and type "bzr init". VoilÃ, my project is under bzr.
I use bzr because I can commit even when I'm offline and I'm not afraid of small untested commits because they are local. It's really a lot more confortable.
I use bzr because if I want to test something on an existing project, I know that branching and merging will be trivial. By comparison, just look at how many pages the branching chapter of the subversion book has.
I use bzr because I cannot use svn without breaking my local folder every week. I very often delete and rename file with using the svn command. I move a complete folder and, poof, all is broken. It takes a lot of time to repaire. Most of the time, I end by doing a new checkout and manually copying the modified files in the new checkout. When it happens, I hate subversion. Really. I also cannot recommand svn for non geek users. Bzr simply works and I never had any problem like that.
Finally, I use bzr because I don't care about my VCS, I just use it. Bzr is still young. The documentation is far from perfect. Using it is easing but advanced stuff like setting a shared server over Apache are still not well documented and not features complete but, still, if you take a few days/weeks to learn it then to use it, you will wonder how you have been doing before. Really
Ploum.net.