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."
Familiarity? (Score:5, Insightful)
Integration in common tools (Score:3, Insightful)
Git is not well supported on Windows like Subversion is with turtoiseSVN. There is no good integration in Eclipse or Netbeans. The workflow is more complicated and enterprise tools such as Jira and Confluence do not support it.
These things may improve but right now, Git is not very well suited for use in corporate environments.
Re:IDE Integration (Score:5, Insightful)
Clearly, you've never used git to think that some UI can make subversion usable.. Try merging a reasonably-sized branch with subversion (and you'll fail and cry and ask why oh why you didnt use git).
Re:my choice (Score:4, Insightful)
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. If, in the future, you and your team decide you need to change how you do source control, then git, or some other distribute peer-to-peer system, might be the solution. But don't just use it as a drop-in replacement for centralized server development.
Re:go with Perforce (Score:5, Insightful)
>Note that Perforce is free for open source projects.
Yeah, so was BitKeeper and that used to really work too.
Re:my choice (Score:2, Insightful)
I'm in the same camp. I have to manage version control with some less than sophisticated Windows-based web guys, and TortiseSVN works well for that purpose.
Personally, I come from a CVS on UNIX background so the smooth repository transition and similar commands and usage style were handy. All I needed out of a "better CVS" was the ability to version file name changes. If you aren't coming from CVS, I think SVN loses much of its charm.
I'd be all over Git if I thought distributed repositories would be helpful for my projects, and I'm thinking of tooling around a little with it on the side just to keep up on all this new fangled stuff you kids are using these days.
Rails, not so much. It looks nice, but it tickles my "get off my lawn" reflex.
Re:Because... (Score:2, Insightful)
I've been using Subversion largely through the eclipse plugins for a while, on a couple of different platforms. I would characterize the Eclipse integration (Subversion) as fairly mature, and it has exhibited recovery for me across a few different hilarious network failures, which caused me difficulties (and delta corruptions) on the commercial products i'd used previously.
Benefits of Subversion:
1. It's been working for a while, the last thing I need to do with my copious spare time is switch over to a new VCS mid-project.
2. MacOSX version that works without having to deal with endless recompile/experimentation. Right now, it's a PITA to get git working under MacOSX.
3. It's easier to back up a central server than it is to get developers to back up their machines on a regular basis. Who wants to risk losing code?
4. I'm working for a startup. Right now, I'm evaluating VC systems on one basis -- and it isn't novelty, it's whether it does a job in an appropriate way without taking resources away from doing other high priority tasks. GIT (as of a month ago at least), hadn't reached that level of seamlessness.
5. Good tools exist that non-technical people can use to check things in and out of SVN on a variety of platforms.
--Corprew
(and for those wondering, SVN works fine with the free AptanaStudio plugin that lets you write rails/ruby in Eclipse)
Re:IDE Integration (Score:5, Insightful)
You feel free to wait around for "integration". The command-line client is already nicely integrated into my IDE, which is the most mature, most stable, and most flexible one in widespread use: Unix.
Re:IDE Integration (Score:5, Insightful)
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? Of course, it is always possible that I have a dysfunctional relation with myself.
I can't speak for how awesome git is, I've never used it.
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.
Re:Command line is easier (Score:3, Insightful)
For example, my IDE (IntelliJ IDEA) allows me to view history for a _selected_ _class_ or even a piece of code. Even across branches and merges.
Try to do it from a command line (you can, but you'll need a lot of 'blame' and 'log' commands).
Re:IDE Integration (Score:3, Insightful)
Branching and merging is a fact of life. If you don't branch or merge, likely your project is either trivial or your pool of developers small. Larger projects with many developers require the ability to branch and merge large bodies of code. Attributing this fact to personalities is nothing but hand waving. Personality conflicts may be the root-cause for you but is not the root for the majority of people that require such functionality.
Simple fact is, branching and merging is required for complex software development. In part, that's why git was developed in the first place.
Re:My own opinion (prob. very controversial) (Score:5, Insightful)
You've obviously never worked on a programming team.
The best reason to use CVS or Git is the situation where multiple programmers are touching the same file(s) at once and you need to both commit. Also, the blame tool on SVN lets you easily tell when any given line of the code was added and why (see the commit message). The SVN repository I work on professionally has well over 25K commits...try managing that with a bunch of copies and text files!
(I've done the versioned tarballs for a project I worked on alone...never again!)
Re:CVS all the way baby (Score:3, Insightful)
Re:my choice (Score:3, Insightful)
I'm not afraid of the command line, but I'll be damned if I'm going back to IDE-less development for any project more complex than a simple webapp.
I don't use Windows for development, but I DO need my IDEs.
Git fails because of the lack of integration. Until it has that, it does not fit my needs. What's more, it fails to start with because they didn't consider that in the first place. A "simple text editor" dev environment stopped being useful or productive back in the 90s.
Re:IDE Integration (Score:5, Insightful)
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.
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.
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. The whole point of branching is to increase complexity, and excess complexity is the enemy of every good software project. As Occam's razor says, you shouldn't multiply entities beyond that which is strictly necessary.
That's not to say I never branch. But it's always a last resort for me, no matter how awesome the source control system is.
Re:my choice (Score:2, Insightful)
A "simple text editor" dev environment stopped being useful or productive back in the 90s.
They don't exist (Score:3, Insightful)
There is no such thing as a "die hard" subversion fan. People use subversion because they already use subversion. Not because they are fanatical about their choice. Which sets them apart from people who go for Git, Mercurial, etc. it puts subversion people roughly in the same group as CVS people.
It's hard to be fanatical about the philosophy of "if it ain't broke, don't fix it"
Re:IDE Integration (Score:4, Insightful)
There are a lot of times I don't branch, but it's usually out of laziness and I end up regretting it at some point in the project.
Easily, the most common reason for branching is a stable-versus-development split. I've run into it in virtually every project I've been on that involved any other people (even just as employer), and even a number of my personal projects. Stable branches almost always need an occasional bugfix or super-quick feature that I can be reasonably sure to get in in a one or two commits, and typically these things need to go out ASAP. I've run into that a million times with copy changes. In programming world, copy changes are usually the lowest possible priority thing, but with clients they're often some of the highest priority.
Point being, if I'm ever working on adding some major feature--really anything that will take more than a couple days, and sometimes even when it won't--I'm likely going to be better served doing it in a branch. If it happens that I get through it without needing to make any changes to the stable code, sweet! The merge is going to be super quick and easy. If not I'm going to be very glad I took the time to branch or regret not having done so. "I can't make your change right now because I have a ton of half-finished in-development code" is not an excuse people are interested in hearing.
Re:IDE Integration (Score:4, Insightful)
Easily, the most common reason for branching is a stable-versus-development split.
I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?
I've run into that a million times with copy changes. In programming world, copy changes are usually the lowest possible priority thing, but with clients they're often some of the highest priority.
Yes, you could solve the problem that way. I normally solve it by releasing frequently. It's pretty rare that people mind waiting a few days. Or if they need to change copy a lot, by putting the copy in a content management system, so they can change it whenever they get the urge.
I can't make your change right now because I have a ton of half-finished in-development code
I solve that by not having a ton of half-finished code. Ship early, ship often, I say.
Re:IDE Integration (Score:5, Insightful)
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.
So you've never implemented something and then wished you could revert a change that didn't work out? Or have never wanted to incrementally implement something without incorporating it into the final product until it was fully complete? Really?
Re:IDE Integration (Score:3, Insightful)
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.
This is back to my original point. If I'm working with people who are regularly checking in bad code, then I solve that by talking with the person. Why would I let him go on doing dumb things any longer than necessary?
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?
I mainly solve this by making sure it doesn't happen much. Branching can only save you if you realize it's a bad idea before you merge to trunk, only if your changes are mostly bad. I think the solution to bad ideas is better product management, not better version control.
Have you read what you just wrote here? Ofcourse the point of branching is not to increase complexity. It's to reduce it.
Let's take a simple example. Me and my team are developing against trunk, committing every few hours, and shipping weekly. How many relevant versions of the software are there?
I count 2. One's in production, and one's at the head of the trunk. The divergence between the two is at maximum, however much the team can develop in a week.
Now I branch. How many interesting versions are there? I count 3. How much divergence is there? Well, there's release to head, release to branch, and branch to head.
So that's 2 versions with 1 axis of divergence, versus 3 versions with 3 axes of divergence.
No matter how you measure it, that is increased complexity.
Re:Exactly. Use a solution for modern problems (Score:3, Insightful)
Re:IDE Integration (Score:3, Insightful)
I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?
When adding a new feature that might take 2-3 weeks to be "stable", do you use a different system to back up your work each day? Wouldn't it be easier to make a branch you could commit to back up to each day, then merge it in when your branch is stable?
Re:IDE Integration (Score:3, Insightful)
I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?
Yeah, and it'd also be nice if software was released without bugs. Every non-trivial change (and more trivial changes than you or I would like to think) introduces the chance for an unintended consequence. If you are attempting to ship a solid product and you need a critical bug fix ASAP, you really want to start from EXACTLY the code you shipped last time and make the minimum change to fix the critical bug.
For some, especially informal users, a frequent release schedule with lots of miscellaneous changes irrelevant to their purposes might be ok. In many professional environments, that's a big problem. Ship early ship often is not a recipe for being taken seriously in a lot of businesses.
Re:IDE Integration (Score:3, Insightful)
When adding a new feature that might take 2-3 weeks to be "stable", do you use a different system to back up your work each day?
I don't check in things that I don't think are stable. I do that primarily through test-driven development and pair programming, plus automated acceptance testing and showing new versions to product management and/or QA every few hours.
Bugs only get harder to find over time. It seems a lot cheaper to me to kill them dead as soon as possible, rather than storing them up and trying to find them later.
Re:IDE Integration (Score:4, Insightful)
You can always tell when someone is making an unfounded claim based on their own narrow experience being all that matters: They say "Period" at the end.
Some large projects are organized and run in ways that require branching and merging. Some are organized and run in ways that don't. Generally these decisions are mandated by factors that have nothing to with any developers preference about source control or anything else, but are based on the external nature of the project at hand or management decisions or whatever.
As far as reccomendations:
I work on a project that does very little branching & merging. We use SVN, and I like it (Tortoise in particular) very much, so I recommend it if you don't need a lot of branching and merging. If you do need a lot of branching and merging, I've heard it's a PITA, so you should check into that. You probably know if you do, or will do, a lot of branching and merging, and you should choose an SVN system based on that, and not worry what anyone else thinks it says about the size of your project or ability to form teams.
Re:IDE Integration (Score:3, Insightful)
I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?
Not always.
In the real world, a development branch often requires coordination between multiple programmers; I change the broken API to FooLib. I know that this breaks the callers, but that's okay because we're working in the "big changes to FooLib" branch. I test that FooLib 2.0 works okay, then check it in to the dev branch. The rest of the team updates their code bases which use FooLib to the new APIs and check them in. Nothing's merged into any live branch until it's all integrated and tested. In the meantime, the stable branch continues to work.
Or I write the tests for the new refactor, commit them (all broken), and then another programmer pulls them down and does the refactor. In the meantime, you still have a working test suite for the stable branch that's not showing false negatives.
That's even leaving aside the much more obvious cases of "this is a massive change that's going to result in several days' breakage as we all work through it", where you have several developers who need to coordinate their efforts (and probably use many of the tools that a decent VCS gives them) and also don't want to have floating changes sitting outside the repository for days at a time (in case, say, a dev gets the flu and you need to continue working without trying to get at his personal machine or duplicate his work).
And, of course, even if you write decent tests and are cautious about commits, it's entirely possible that you'll miss some bug (it may only show up in a certain environment, or you missed an obvious test case, or whatever). On even a medium-sized project, you don't want to supplant the stable code until there's been a whole heck of a lot more testing than just one programmer who thinks he's written good tests and done plenty of his own integration testing.
Heck, you may even need to support the users who are running the old code for a long time, and have to keep doing bug fixes for them while most of the world is on the newer codebase.
Re:Keyword: Herd (Score:5, Insightful)
I like to use git because I find it easy to make a branch for testing out some new code, and easy to merge the branch into the trunk if I want to keep it. Here are some aliases I wrote that cover pretty much all the git I use. If I decide to change version control systems, I can change the aliases. alias vca='git add .';
alias vcb='git branch';
alias vcc='git commit -a';
alias vcd='git diff';
alias vcm='git merge';
alias vco='git checkout';
As for choosing between git and subversion, why not try both? It's pretty unlikely that somebody will tell you what you like best. You have to find out for yourself. Considering that they are free software, easy to install, and pretty easy to use, you can try both and see if one of them seems better to you. I tried both, and I chose git. But I don't mind if other people use subversion, RCS, SCCS, or whatever they feel like using.
Subversion and git have different models. Subversion has a client-server model with the repository accessible by http. Git uses a distributed model, with each user getting their own copy of the repository, and the possibility of merging things from one repository to another. This might make git work better if the users' computers aren't always able to connect to a remote repository.
Try them both, see which one you prefer.
Re:Windows. (Score:3, Insightful)
Another factor in a Windows-centric corporate environment, SVN will function very usefully without a server. While I would prefer to have a proper repository server, the IT departments of most of my clients simply refuse to support anything outside a small range of "corporate esentials". Since a SVN repository on a file share is better than no VCS, that's what ends up being used.
Re:IDE Integration (Score:5, Insightful)
So I guess you've never worked in the real world, where corporate mandates a change that has to go out before EOB same day, or where you are half way through a feature set impl, and management changes the priorities. What do you do with that code then? Or when the CTO ups and quits, and his info has to be yanked from the website in 30 minutes or less.
Often you need three branches at least, one for dev, one for staging, and one for production. And that's not counting the system rewrite branch that might be bumbling along in the background perpetuated by another developer whose been assigned to fixing all the wrongs in the current system.
And let's not even start down the path of trying to integrate people's work in subversion who are in a big team when someone has gone three weeks without a commit because they are working on a major new feature. And that's not even starting to talk about database updates and how they have to be applied in the process between co-ordinating developers.
Then we can talk about the offshore development team who isn't trusted to put changes into the main branch without a peer review from someone onshore.
And then you get sued by a competitor who accuses you of stealing their code because you hired one of their developers and they have some random bit of proof, so you have to make a new branch to incorporate whatever random changes legal decides are appropriate to mitigate that, that have to be reviewed by an independent third party who takes three weeks to do anything, and you can't just stop development and wait for them.
And what happens when you have to update the docs that should be in version control too for someone else, particularly manuals for a release that is concurrent with ongoing development, or even historic because something somebody put in the manual six months ago has turned out to be wrong, and they have to be updated for that release that people are still buying.
Showing product to the client (because that's who really calls the shots, not the product manager) every few hours is just plain impractical. Most people don't want to see updates every few hours, they want a finished product in clear review cycles. They don't have the time to review the entire system every few days let alone every few hours. A full QA cycle for a normal sized product can last a week. Do you just stop development while they do a full QA before a release?
And let's not even mention bugs that are transient and may only show up six months down the road when more people start using the system, like race conditions which have become apparent in code that was written two years ago and nobody remembers for toffee. What about storage checking - the system was written by someone who thought that storage would never run out, so why check to see if there is enough space on the disk to complete the operation, and the application crashes and is down for a while while some poor sysadmin tries to find more disk space.
And the application that wasn't maxing out the network until it was deployed at a client with 300 users, and now you have to go back and rework your com model from a year ago. It's not exactly a bug, but you're gonna have to fix it anyway.
What about a large scale integration with a pre-existing piece of software that might take a month to complete? You can unit test each piece of it sure, but you can't release the whole thing until the integration is totally complete.
There are SO many reasons you have to have branches in the real world.
Re:IDE Integration (Score:3, Insightful)
So you've never implemented something and then wished you could revert a change that didn't work out?
Are you saying your SCM doesn't let you revert/rollback without branching? Please tell me what SCM that is so I NEVER EVER EVER think about using it.
Or have never wanted to incrementally implement something without incorporating it into the final product until it was fully complete?
Since it's merging that is the problem and not branching, why would this scenario cause a problem. Branch of your release code, that should not have any significant work done on it, and do all you work in your main line, branching only stable code for the next release.
How people get anything done with their convoluted source control management totally amazes me sometimes.
Re:IDE Integration (Score:3, Insightful)
If I'm keeping track of a bunch of branches in my head, then that limits the amount of other stuff I can keep track of.
But the idea is that if your project demands you keep track of these things anyway, branching can help ease that burden.
The time I and the people on my team spend talking about the different branches is time we can't talk about actual features. If my ops guy or my product manager has to figure out what's where and what's elsewhere, then that's time, attention, and energy that they can't put into what they're really there for.
That's not at all applicable to the kind of local branching used in Git and Bzr, for the reasons I outlined in the previous post. You can make a gazillion branches in your local copy of the Git repository, and your ops guy and product manager won't even see them unless you explicitly push them back to the central repo.
As it turns out, the awesomeness of Git (and certain other distributed SCMs) can reduce that human cost to zero.
Re:IDE Integration (Score:3, Insightful)
Are you saying your SCM doesn't let you revert/rollback without branching?
Are you saying that you enjoy having mainline broken while people are incrementally working on major code changes? Ignoring the fact that reverting changes can be a pain in the ass when multiple people are working on the same codebase.
Since it's merging that is the problem and not branching,
It is? Funny, I've never had that problem. Perhaps you should mention it to all those distributed SCM users. Even with subversion, merge management isn't that tough, as long as you're diligent and keep your working branch in sync with the eventual merge target.
. Branch of your release code, that should not have any significant work done on it, and do all you work in your main line,
So that my code can become broken while another developer incrementally works on a major change? Thanks but no thanks. I've experienced that, and it is, to say the least, really *really* annoying.
Not to mention the case where developer X is working on some major feature, and then scheduling restrictions force the team to push said feature out, into the next release. Which is easier? Delaying the merge, or reverting all the changes?
How people get anything done with their convoluted source control management totally amazes me sometimes.
Convoluted? How? I'm about to create new major feature X. I create a branch myproduct-feature-X. I work on that branch. When it's done, perhaps I send out a code review request, including the branch name. When I'm done, I instruct my SCM to merge from the branch back to trunk.
This is a *far* more sane way to manage major changes. It facilitates code review, makes it easy to gate changes through a change control system, and allows developers to use the full power of an SCM for incremental development. It's only convoluted to those who don't understand basic source control concepts.
I don't care (Score:1, Insightful)
I see discussions like this all the time: "Emacs is better than Vim", "Git is better than CVS", ...
And I must say, I don't get it. Why is this stuff so important? I've seen people type really fast in their super-editor, and commit and branch their code faster and more efficient then you could ever imagine. But I've also seen the same people produce crappy software while doing this.
So, is this question really that important?
Re:my choice (Score:3, Insightful)
An IDE would have caught that typo.
Re:IDE Integration (Score:4, Insightful)
Admittedly my code is rarely ever rolled back, but when I do have to it's as easy as choosing the commits included and in that piece of code and removing them.
Which is non-trivial when multiple people are working on the same codebase. It's the precise reverse of the merge problem. Although I would contend it's actually conceptually harder. It's much easier to look at a pair of changes and merge them, either automatically or manually. But trying to unwind two sets of intertwined changes is not my idea of a fun time.
I'm not against distributed SCM in anyway, but I will say that from everything I have read distributed SCM does not alleviate the need for manual conflict resolution in anyway shape or form
I never said it did. What I said was that users of distributed SCMs have discovered that conflicts simply aren't that big of a problem in everyday use.
Why do you have broken code in your working copy?
I don't have broken code in my working copy. I have in-progress code in my working branch. Why do I have that? Because the SCM exists to hold my code. It allows me to compare my code against mainline so I can review my changes. It allows me to incrementally update and revert my work as I go along. It allows me to ensure that all my changes are in an SCM which is backed up daily, so that I don't have to worry if my desktop crashes. It allows me to work in multiple locations on the same codebase. In short, it lets me use the SCM to manage my sourcecode, both my in-progress, working efforts, as well as the stable, in-production codebase.
Besides which, you seem to have this rosey picture that every commit is a good one. Believe it or not, people make mistakes. And when the guy down the hall accidentally breaks the database because his upgrade script is slightly b0rked, I don't want to waste time while they get their shit together.
And why is anyone committing code that either does not compile or does not pass your unit test suite?
Because no test suite covers all bases. And because people simply make mistakes.
Honestly, have you actually developed in the real world?
Huh? Why revert or delay anything.
I see you've completely missed the point. Here, let me be more explicit:
1. Project X has a deadline looming. In project X, management has scheduled features 1, 2, and 3 to be included.
2. A month before the deadline hits, the developers for feature 3 report that they are behind schedule and that feature 3 will have to be excluded from the release.
3. ?
The question is, what do you do at step 3. If you believe that all development should happen in trunk, then the developers now have to find a way to revert all the changes that make up feature 3 (naturally they've been using the SCM to interact amongst themselves). This could be an extremely non-trivial task depending on the complexity of the change.
Or, if you believe that all major development such as this should happen in branches, then the managers need only decide not to incorporate the changes from feature 3 into trunk.
And if you've never encountered this situation, I strongly question your experience, as this is pretty typical (just ask Microsoft about how WinFS is going).
Branch out only the stable code into your release branch.
Ha ha ha. Okay, now you're just being funny, right? What, you think you can just cherrypick changesets and build a release? Have you never built a large, non-trivial application with multiple developers? Or a database driven application where multiple, interlinked changes need to be made to the schema? Sorry, but the interdependency between changesets means that's just unrealistic in practice. And I've seen it tried... it ain't pretty, to say the least. Just the process of trawling through the changelog to identify all the mods that went into some feature, so that you can revert them, is an absolute frickin' nightmare. And that's ignoring the process of actually revertin
Back to Basics (Score:1, Insightful)
Find out what Version Control systems the developers of Subversion and Git were using when they wrote their code.