If you're looking for corporate git, take a look at gerrit. I think it addresses many of the concerns raised below.
On 11/03/2012, at 13:38, David Weintraub <qazw...@gmail.com> wrote: > 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
