From: Marat Radchenko <marat@slonopotamus.org>
To: git@vger.kernel.org
Subject: One MMORPG git facts
Date: Thu, 25 Aug 2011 06:53:57 +0000 (UTC) [thread overview]
Message-ID: <loom.20110825T081519-218@post.gmane.org> (raw)
In-Reply-To: 416D1A48-9916-4E44-A200-3A13C39C4D70@gmail.com
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.
next prev parent reply other threads:[~2011-08-25 6:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-23 23:06 git for game development? Lawrence Brett
2011-08-23 23:32 ` Junio C Hamano
2011-08-24 1:24 ` Jeff King
2011-08-24 17:17 ` Junio C Hamano
2011-08-24 18:26 ` Jeff King
2011-08-27 15:32 ` Michael Witten
2011-08-25 6:53 ` Marat Radchenko [this message]
2011-08-25 7:57 ` One MMORPG git facts J.H.
2011-08-25 16:02 ` Marat Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20110825T081519-218@post.gmane.org \
--to=marat@slonopotamus.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).