That is an absolutely great summary ! -----Original Message----- From: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] On Behalf Of David Weintraub Sent: Sunday, 11 March 2012 3:38 p.m. To: jenkinsci-users@googlegroups.com Subject: Re: Git vs SVN
Git is not "better" than Subversion. Distributed version control is not "better" than centralized version control. However, that doesn't mean that Subversion is better or that centralized is better. It's all about circumstances. There are many circumstances where Git excels. I use Git as my person version control system, and I even have projects on GitHub (including several Subversion hooks). Using Git is easier than using Subversion when I'm the only one using it. No need for starting or stopping a Subversion server. And, GitHub makes it ridiculously easy to share it. Git has another advantage too. I've had people who've downloaded my work, made changes, then sent me -- via email, the Git patches. I can review them, and then add them back into my GitHub repository. Git makes it easy because everyone has a repository, and each repository can accept patches from other repositories. So, if I find Git so useful, why don't I introduce it to our corporate environments? Git has two main powers: Distributed repositories and a lackadaisical attitude towards security. This works great for Linux. Torvalds only has to accept changes from two or three people. Everyone else who wants to contribute to Linux has to find a sponsor who will accept their changes into their sponsor's repository. Those sponsors have sponsors, and onwards to the official Linux repository. tens of thousands of people might be making code changes in Linux, but all Torvalds has to know are the two or three people he'll accept changes from. It's a web of trust. Now, let's look at a typical corporate environment. With an open source project, if tens of thousands of people have your source code, it's a smashing success. If you're a bank, and tens of thousands of people have access to the source of your trading algorithms, it's not a success. You need a centralized security system. Let's look at how the corporate development works. There is one, and only one repository that's official. All the desktop repos mean nothing. All the shared team repos mean nothing. Unless it's in the official corporate repository, it means nothing. That means Git's true strengths, it's easy attitude towards security, and the power of its distributed repository are rendered null and void. The true advantages it would have over a centralized system like Subversion just don't matter. A long time ago, I was a ClearCase administrator. ClearCase uses the idea of "streams" (branches really). Developers work on their private "development stream", and then deliver (merge) their change onto the "integration stream". It was the integration stream where builds would take place. It's all the disadvantages of a centralized repository system with all the disadvantages of a distributed repository system. My job as CM was mother hen. I would walk around and pester the developers to commit their changes or rebase their stream (i.e. merge the changes in the integration code into their branch). If I was lucky, we would somehow avoid the merge hell that release dates became. I had QA on my back because they would never have enough time to actually test everything. My first job outside of ClearCase was at a shop with three dozen or so developers all using CVS. How do they create developer branches? They don't. Instead, they all work on the same mainline branch. In fact, they rarely ever branches. Well, I thought, this wouldn't work. I was wrong. I never saw a development shop run so smoothly. Developers took small bites in their changes. They were more careful in what they were doing and how those change might affect other developers. Come release time, QA had already tested almost all of the changes. Instead, they pointed out the bugs that were patched. When it was time to release the code, it was tested and there was little last minute crunch. I suddenly realized what forcing everyone to work on a centralized repository would do. It forced everyone to work together. It forced people to communicate with each other. It forced developers to think before they made any changes. And, that's why Subversion might be better in a corporate environment. In fact, in some ways, Git is worse than ClearCase UCM. At least under ClearCase UCM I could peek at the developer's work and know what to expect when the "delivery" took place. It was in their own branch, but it was accessible in the repository. With Git, I wouldn't even have that. A developer might be working on a walloping change, and I have no way of knowing until they present it three days before the release. Subversion is also simpler than Git. A public Git repository still depends upon SSH for security which makes it harder to setup. With Subversion, I can use Windows Active Directory. You know your Windows account and password, you know your Subversion account and password. If you are in the "development" Windows group, you have access to the repository. Git requires a commit and a push to get your code into the main repository. In Subversion, a simple commit does the trick. If you do a "svn status", you know whether your code is in the main repository or not. A "git status" doesn't. There have been too many "whoops" occasions when someone thought they had submitted their change to the main repository with Git but forgot. Git is just another tool in your toolbox - like a hammer. It can be good to use sometime, but you can't treat everything like a nail. Git isn't a miracle detergent that will get your clothes cleaner, make your colors brighter and your whites even whiter. Let's look at what you're asking: * All developers will have to be retrained on Git. * All Jenkins jobs will have to be modified to use Git. * You're going to have to convert your repositories from Subversion to Git. * If you're using a defect tracking system, you'll have to modify that to use Git. * If you're using Maven, there are going to be some changes in your pom.xml files. And all for what? Don't give me an evangelical list of advantages. We're not saving souls. We're building software. What advantages will Git offer at your company? What makes it so good that it's worth the headaches that will accompany the change. I've done this before taking companies from ClearCase to Subversion, but I was able to easily convince all the stakeholders of the advantages. Ask yourself what problems Subversion presents and what problems Git will solve. If the developers are happy with Subversion, and there aren't any issues that Git will solve, then what are you trying to do? -- David Weintraub qazw...@gmail.com
