Lawrence Brett <lcbrett <at> gmail.com> writes: > > Hello, > > I am very interested in using git for game development. I will be working > with a lot of binaries (textures, 3d assets, etc.) in addition to source > files. I'd like to be able to version these files, but I understand that > big binaries aren't git's forte. Define "big". I have one MMORPG here under Git. 250k revisions, 500k files in working dir (7Gb), 200 commits daily, 250Gb Git repo, SVN upstream repo of ~1Tb. Some facts: 1. It is unusable on 32bit machine (here and there hits memory limit for a single process 2. It is unusable on Windows (because there's no 64bit msysgit) 3. git status is 3s with hot disk caches (7mins with cold) 4. History traversal means really massive I/O. 5. Current setup: 120Gb 10k rpm disk for everything but .git/objects/pack, separate 500Gb (will be upgraded to 1Tb soon) disk for packs 6. git gc is PAIN. I do it on weekends because it takes more than a day to run. Also, limits for git pack-objects should be configured VERY carefully, it can either run out of ram or take weeks to run if configured improperly. 7. With default gc settings, git wants to gc daily (but gc takes more than a day, so if you follow its desire, you're in gc loop). I set objects limit to a very high value and invoke gc manually. 8. svn users cannot sensibly do status on whole working copy (more than 10 mins) 9. svn users only update witha nightly script (40 mins) 10. git commit is several seconds because it writes 70Mb commit file. 11. It is a good idea to run git status often so that working copy info isn't evicted from OS disk caches (remember, 3s vs 7min) 12. Cloning git repo is one more pain. 100mbps network here, so fetching 250Gb takes some time. But worse, if cloning via git:// protocol, after fetching git sits for several hours in "Resolving deltas" stage. So, for initial cloning rsync is used. 13. Here and there i hit scalability issues in various git commands (which i report to maillist and most [well, all, except the one i reported this week] of which get fixed) Hope this helps to get the idea of how git behaves on a large scale. Overall, i'm happy with it and won't return to svn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html