So basically, more moving parts means it takes more time to figure it out. For you or me, that's an inconvenience and then happiness about all the cool features and capabilities. For a corporation trying to keep their training budget low, that's a non-starter.
Use the default.
> and repository (bare or not)
Use the default.
> more ways to edit changes (cherrypicking, rebasing)
Use the same ones you use in svn.
> more moving parts
git has four object types that are put together very naturally (tags contain commits which each contain a reference to a parent commit and a tree which contains a collection of other trees and blobs).
This means that when something goes wrong, I can fix it.
svn has at least two server-side object formats, and various version changes that make some features available or not based on client and server capabilities.
Backups are harder, repair is harder, history traversal is harder, sending changes around is at the very least slower.
In my experience, interacting with git is no harder. I've taught many people how to use it and the only people who were remotely confused were those with a svn background, as the svn unlearning process generally takes more time than the git learning process.
While both were faster than SVN (often much faster), they have huge disk footprints compared to an SVN working copy. In our case, the SVN working copy was ~1GB, and both the git and hg repositories were over 20GB. That matters when you have an 80GB SSD.
Also, since neither git nor hg let you check out a subset of the repository, we'd have been forced to break things up into lots of smaller, separate repositories, a prospect we dread.
Admittedly, we do some stuff that is questionable, like storing images and libraries, but we like keeping all the content the code uses and the code itself together.
For some newer, more isolated projects, like our mobile code bases (iPhone, Android, etc), we use git and love it. But for our 4 year old server with over 100 projects, we couldn't realistically make the switch.
Not questionable at all. We do the same thing, all the way down to storing tarballs of software-packages a project depends on - it is the right way. The blame is on git here for not supporting it better. I.e. it should be much easier to selectively truncate history or even define an object-level attribute like "Only keep the last 3 versions of this".
Regardless we're getting along with git quite well, despite .git sizes in the gigabytes for some projects.
Our main complaints about git are access control and sub-projects at this point.
Subprojects ("submodules") in git are a royal pain in the ass. I consider them broken-by-design. A simple equivalent to svn-externals would work so much better...
This, combined with the complete lack of directory based access control, makes it rather cumbersome to work with "partially trusted" third parties in a commercial setting. We don't want to open our entire repository to some temporary contractor. Neither have we found the hassle of git submodules worthwhile for this purpose.
That's why we're still using SVN in this area, although I'd much prefer if we didn't have to.
I suppose partial checkouts are critical for several other fields - for e.g. take a look at a similar request for Mercurial (http://mercurial.selenic.com/bts/issue105) Message 8102:
Two of the features that made it difficult to 'sell' Hg for the main SCM of FreeBSD were the lack of partial checkouts and partial history
And because of the way legacy code is structured, this gives rise to issues like this one - http://jira.codehaus.org/browse/MRELEASE-457
For several use cases, this is a highly critical feature and the reason that SVN may win over finally - perhaps as SVK (svn's distributed revision control fork)
<empirical-observation> The transition from cvs to svn happened very quickly, to the extent that it is now the predominant SCM. The migration tools are robust today, but they were not so a couple of years back - which is why it is even more suprising that people were willing to undergo the cvs2svn pain but are not willing to do the relatively painless 'git svn clone'. Maybe git truly doesnt suffice in a LOT of situations. </empirical-observation>
* No GUI for Git on Windows
* Everything knows how to work with Subversion already (tools, testing, continuous integration, idiots)
* Companies like centrally controlled and backed up solutions
* Why change when what you have works for you
git wins fast over svn for backups.
git backups are redundant, always up-to-date, easily verifiable, and easy to turn into proper master repositories.
The more people you have working on a project, the harder it gets for anything to get lost.
If you are comfortable with SVN then by all means use it but if you haven't at least tried Git you are missing out on some really powerful tools and workflow possibilities.
If you have a lot of binary files then maybe subversion might be a better fit for you. But even then the local directory size can be smaller with Git.
I think the biggest challenge with using Git in a large organization is training a large number of people to use it. You can do a fair amount of development on a Subversion project knowing just how to update and commit. The same does not hold true of Git.
Well sometimes your co workers are too .... old fashioned... to grok git. Work in a large enterprise sw company to see this at full effect.
Quote: "More than one-third of developers use Subversion for source code management; that's almost triple the share of the next most used SCM tool, Microsoft SourceSafe"
