Hello list,

I have been monitoring this thread and thought to share this absolutely great summary by David that I found recently posted on the Jenkins mailing list that suits apt for this conversation. I agree with all his points.

Original thread here --


<snip of Darryl's update>

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

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


You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to