Git on large projects

Pipelines
1

I was wondering about git’s performance when dealing with a large number of binary files. We keep all code, compiled binaries and content in perforce and when making a new branch or syncing up to one is a huge time sink. Not to mention the disk space requirements.

How does git perform when you have a huge repository with lots of large binary files when you switch/create branches?

Has anyone used git on large projects?

2

http://stevehanov.ca/blog/index.php?id=50

3

(Haven’t used GIT) but we did have discipline specific workspaces so most people wouldn’t have to sync a whole project.

4

[QUOTE=Theodox;21373]Why Perforce is more scalable than Git

Most of the things he wished for are available in Perforce now (shelving for instance)

5

Yeah, I actually just tried to use Git on a 6gb repo, with lots of binary files. Its a non-starter. It would take upwards of 2 minutes (on the high end) to just check the status of the repo, let alone submit.

Some advice:

  • If you want to use git or mercurial, as mentioned, try to limit it to what you’re currently working on (ie a couple of libraries, an exporter .sln, etc)
  • Branching is great if you’re working in the building. Sure it takes a bit of time to do the initial setup, but once you’re done, its really quick
  • If you’re looking for the decentralized (no central version control server) aspect that git provides, look into p4 sandboxes and streams. They have been invaluable to some stuff I’ve been working on in my spare time.
  • Shelving is good for some small changes to a handful of files, but can get difficult to manage pretty quickly

Hope this helps!

6

I recommend seriously considering the intended user base before adopting git.
We use git in our studio , and I pine for something like perforce.

While the coders seem to love git, for our art department it’s barely usable.
when it goes smoothly, basic checkout/in ops are of forgivable complexity.
but when it goes less than smoothly , which happens much too often (i.e., git won’t let you check things in/out because it detects some issue)
you basically need a git guru around to unf**k things for you.

7

We use a combination of git and perforce with bindings between. Git is used for code and scripts, while perforce houses all the game content. The artists don’t pull the code, and the engineers don’t pull the binaries (only the assets). Git really isn’t for binaries – its usefulness lies in the ability to branch and merge. Although p4 does have streams and shelving now, git is good for making sure you are deploying the correct versions of tools and compiled code to the team. Hopefully, Content would be able to just run a script to pull the right branch.

To your specific question, I don’t think using git for art binaries is the best solution. Not only is your sync going to be slow, as others have mentioned, but the workflow for git is just miserable for anyone non-technical. This doesn’t just mean it’s a pain in the ass for Art. It means that whenever you have a problem with git that an artist can’t diagnose, he/she takes an engineer down with him, who has to do the git-muscling. Forbid that you have an artist that thinks himself savvy and screws up his git in a painful way :o

If you must give artists git, I’d like to recommend SourceTree. Artists that do have to use git seem happier with this program than gitx. Syncing might have to be done overnight, though!