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."
Comment removed based on user account deletion
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.
How odd that I was just watching a talk that Linus gave at Google. Link to the talk
http://www.youtube.com/watch?v=4XpnKHJAok8
He might not be very objective and his talk obviously only offers one side. Still, might be informative :)
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)
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...
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!
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.
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
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.
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: http://svn.collab.net/repos/svn/trunk
Repository Root: http://svn.collab.net/repos/svn
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.
svn has no merge tracking. That's a pretty crucial feature.
Resolved since SVN 1.5, merge tracking has been added!
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:
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 =)
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.
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.
Retch.
Get your own free personal location tracker
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.
Everything I need to know I learned by killing smart people and eating their brains.
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.