Many companies in the games industry have settled on using Perforce or SVN (or more recently Plastic DVCS) internally as, out of the box, it can handle both code and non-code assets (i.e. large binary files) well in tandem. Git has problems with the latter - people have tried to correct this with solutions like git-annex and git-LFS but these have failed to catch on thus far.
The problem with non-code assets in git is (or at least it was for us) not with such assets being large blobs with weird in-git storage model, but with such assets being _unmergeable_ in case of two parallel edits of the same object.
Since merges are not generally possible (except for some special usecases), one would expect version-control system's help in avoiding parallel edit situation at all. This is where svn's centralized server helps, allowing "pessimistic locking" of certain files and folders.
AFAIK, Plastic also offers such a feature, when git cannot do anything like that by design.
> The problem with non-code assets in git is (or at least it was for us) not with such assets being large blobs with weird in-git storage model, but with such assets being _unmergeable_ in case of two parallel edits of the same object.
I tried storing large images in git once. And one problem was when git would try to do garbage collection every now and then. And start diffing all the images against each other to repack them to use less space. This was very CPU and memory intensive.
I was wondering about this as well. I haven't done much video game dev in the past few years but even in my little indie stuff trying to check files into Git was a bit rough at times. Doable but on a very small scale. I'm surprised Git hasn't been adapted to handle this more natively but I'm curious if there are any trends or directions people are heading in regarding this or if they're still sticking with SVN.
True and as if perforce didn't have enough of a strangle hold on the industry, it's free for small studios under 20 users I believe. So that would include most indie developers.
Hi greggman, not enough for what? Do you mean usability? gitlab, github and bitbucket provide a GUI to git-LFS. Or do you mean not enough documentation or a technical limitation like maximum file size or check-in/out speed or just bugs?
On the other hand, it seems like it makes you wait until you're trying to do a git push before you find out somebody else has it locked already - which seems a bit cruel. The more traditional approach is for the file to be read-only in your working copy, and you use the version control client program to make it writeable (and it then performs the appropriate checks). So if you omit to consult the client program first, you'll get no further than your first attempt to save before you find out.
You need to know it's locked when you open it. Which means you need plugins for popular software. Photoshop, Maya, Unity, 3DSMax, Blender, etc.
P4 has many of these integrations so that artist and other non-technical people will know the moment they open the file that if they want to edit it they need to check it out. Similarly they can choose to check in the changes directly from their asset editing app, not from some separate app. They also need an easy way to find out who has it checked out so they can go over to that person and ask when they'll be able to edit it or if the person forgot to check in their changes.
I've written some in the past as well (http://mayasvn.sourceforge.net/) that would not just check in a Maya file but also check in all the referenced files (otherwise an artist checks in the asset but there are lots of missing textures).
On a subnote: Asking the artist "check this in?" on each save is a bad UX. I tried that and the artists complained since they save all the time (in case their app crashes).
