Why Subversion Still Beats Git (via abcphp.com)(brandonsavage.net)
brandonsavage.net
Why Subversion Still Beats Git (via abcphp.com)
http://www.brandonsavage.net/why-subversion-still-beats-git/
11 comments
>Fundamentally, I see corporate objections to git entirely as a lack of established workflows and repo server management tools
I don't even understand that argument. To me, git feels EXTREMELY enterprisey. You can't USE the tool without defining a workflow, even on a simple project. That to me screams "bureaucratic control wet dream".
Git lacks in the tools department on windows, and in the ability to make "workflow specific gui's" to operate on it. Fix that, and Git wins for 90% of cases vs SVN.
Git is scary at first, but after you use it in the correct configuration for your task, you're like "oh, another tool, one that works pretty well" and you move on. I still feel dude hasn't seen the correct configuration for his task and want to point him at the configuration design bubbles in progit.
I don't even understand that argument. To me, git feels EXTREMELY enterprisey. You can't USE the tool without defining a workflow, even on a simple project. That to me screams "bureaucratic control wet dream".
Git lacks in the tools department on windows, and in the ability to make "workflow specific gui's" to operate on it. Fix that, and Git wins for 90% of cases vs SVN.
Git is scary at first, but after you use it in the correct configuration for your task, you're like "oh, another tool, one that works pretty well" and you move on. I still feel dude hasn't seen the correct configuration for his task and want to point him at the configuration design bubbles in progit.
Corporate America needs a centralized version control system. Subversion still offers this: Subversion centralizes the repository and simply checks out a working copy (versus Git, which gives you a complete repository). Corporate America still needs to have cannonical version numbers, and the ability to see the progress of a product over time as a single line – not a bunch of branches and independent repositories.
While I think I understand what he is saying, there isn't any reason why Git can't be used just like SVN (other than checking out only the latest version, which I wouldn't argue is an advantage). Just because you can branch and merge easily in Git doesn't mean that you have to.
Edited to add the following:
There are some valid reasons for not using Git over SVN, but I find it pretty hard to believe that better branching/merging, offline repo access, and version numbers are among them.
Moving on from something which is already in place and taking care of existing needs, or better GUI tools (in "Corporate Americal" anyway) are certainly valid.
While I think I understand what he is saying, there isn't any reason why Git can't be used just like SVN (other than checking out only the latest version, which I wouldn't argue is an advantage). Just because you can branch and merge easily in Git doesn't mean that you have to.
Edited to add the following:
There are some valid reasons for not using Git over SVN, but I find it pretty hard to believe that better branching/merging, offline repo access, and version numbers are among them.
Moving on from something which is already in place and taking care of existing needs, or better GUI tools (in "Corporate Americal" anyway) are certainly valid.
I think the author fails to notice that with Git you can have your cake and eat it too. We use a centralized canonical repo for each of our projects as well as origin (developer) repos. With branches we can more easily add larger features without polluting the main trunk. With svn, as we all know, branching is a bitch.
I use Mercurial in a corporate environment and we use a central repository to pull from and push to. It's really beneficial to get people actually used to committing by feature or bug fix rather than just in huge batches when they feel like merging.
All of the comments here correctly note that this article is nonsense. Will one of the upvoters please explain why they found this article compelling?
Corporate America still needs to [...] see the progress of a product over time as a single line – not a bunch of branches...
The biggest benefit of git, over svn, I'd argue is actually branch merging and merge conflict-resolution capabilities. Subversion 1.6, however, is supposed to take leaps and bounds to catching up to git (vs. the 1.4 server install I currently work with). The version numbers in git are less intuitive than svn, but I feel thats okay, because tagging is useful in git. The real win for git, is that git works with you and your workflow, and doesn't impose as much workflow as subversion does.
( git-svn absolutely your friend. )
No sense at all in this article. Git can be used functionally identically as svn is and STILL be better than svn (externals, speed, better rename support).
Git is not a source control system. Git is a tool that allows a company to define near ANY source control system. It corporate america's dream tool once they figure out they can have anything with git.
This just sounds like a guy who can't handle branches and uses arguments about a system which requires them instead of learning how to do branches.
Git is not a source control system. Git is a tool that allows a company to define near ANY source control system. It corporate america's dream tool once they figure out they can have anything with git.
This just sounds like a guy who can't handle branches and uses arguments about a system which requires them instead of learning how to do branches.
Git might not be suitable for environments that require, say, robust GUI tools on multiple OSes but that has nothing to with it being distributed. Git didn't invent DVCS after all and its (indirect) ancestry traces right back to 'Corporate America' - BitKeeper is a commercial product used exclusively in corporate settings as was the system that inspired it - SPARCWorks/TeamWare.
I like SVN when working for various companies, as it's a hell of a lot easier to explain to some of the choice employees than Git. That said, I personally consider Git to be the far superior system if you invest the time learning how it works.
If you really need strong central control (the point of the article) then you should also consider Perforce. Non-Disclaimer: I have no association with Perforce and I don't use it unless a client has it as I prefer de-centralized source control.
The strongest arguments I know for Perforce are scaling and performance. Perforce has simply been used for larger projects, on larger servers, by larger companies than just about anything else in existence.
It's also presumably good for companies that, like subversion, it's centralized. But it doesn't have any terribly significant feature improvements over svn, otherwise. The interface is slightly slicker, and the merge works marginally better.
It's also presumably good for companies that, like subversion, it's centralized. But it doesn't have any terribly significant feature improvements over svn, otherwise. The interface is slightly slicker, and the merge works marginally better.
I wish you could see who upvoted articles...
This post doesn't say anything. "Corporate America needs a centralized version control system because it needs [features of centralized version control systems]", but without explanation of why they need it.
The advantage with SVN I think is due the amount of GUI tools avaliable for it. Most notably subclipse.
This is either a statement of fact or a thesis. If it's a fact, then the argument is circular.
This is not an argument at all, but a description of how Subversion works versus Git.
The version numbers in Git are fundamentally canonical. There is a possibility of hash collision, of course, but that's not a real concern of anyone. If the Kernel can work with hash numbers and not have collision issues, then a large corporate product can too. If the argument were that the version numbers must be incremental, I might accept that, but I would like an explanation as to why.
This is a workflow issue, not a problem with git.
Fundamentally, I see corporate objections to git entirely as a lack of established workflows and repo server management tools. Gitosis is nice, but I don't believe it allows for the central control that IT managers want. Also, people have not written O'Reilley books about how to manage a git server in a corporate, centrally controlled environment.