|
We tested git and hg at Loopt: 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.