Dear Unreal Enginers,
It’s 2016 and I wonder if anyone has any fresh new opinions on this topic…
Perforce has been the de-facto standard for storing binary assets.
However with the advent and stabilisation of Git with LFS, it’s looking pretty compelling as an alternative.
I wonder if Perfoce is to be dethroned by this rival nipping at its heals?
Regards,
Minxies
Git + LFS honestly doesn’t work well. I don’t like to be hyperbolic but I really think it’s garbage(as of right now). To be blunt it simply isn’t reliable, the “LFS” part breaks constantly and desyncs from files.
At this moment, Perforce is still the standard and Git + LFS isn’t nipping at anything.
If you want a DVCS alternative, Mercurial with --largeFiles is exactly what Git + LFS is trying to be, but has been around for ages and is much more mature, it’s even supported by some repo websites(Such as Kiln).
Exactly the kind of answer and insights I needed.
Thank you, I’ll give Perforce another shot.
Anyone tried Git+LFS lately, has there been much improvement over the last year? We are feeling stiffled by Perforce’s price structure which won’t leave us room to expand without dumping $10,000-$20,000 that could otherwise be spent on development
I set up a Gitlab server with LFS support late last year, to evaluate its feasibility for upgrading a project team from their current reliance on Subversion. I can attest that Git LFS is nowhere near mature enough to deal with anything other than toy projects.
At first glance it seemed to work okay, filtering out large binary files and pushing them to LFS storage separately. But then getting those files back again was where the trouble started. I’ve had issues with both HTTPS and SSH connections, non-working credential storage, connection timeouts, rate limits, request size limits, and lots of vague error messages. I tried the same with Bitbucket’s ostensibly tried and tested LFS support, but had many of the same issues. I did get everything to work eventually, but it felt very flaky and required lots of manual tweaking to get to work properly on the client side. I really did not like the prospect of having to personally troubleshoot the Git clients installed on every project member’s computer. I also observed a few team members who are less Git-minded than I am, try Git LFS out on their research projects. It mostly resulted in frustration on their side and still required lots of intervention from my side, with no real perceived improvement in speed, reliability or productivity. Basically nobody besides me saw the point in using Git over what we already had. In the end we simply decided to stick with Subversion for the time being and take a serious look at Perforce in the near future.
I still think Git LFS has a lot of potential, but it needs to do a LOT of improving in usability on both the server and client side for it to be practical on any non-trivial projects. Some people may claim to have had success with it already, but I seriously doubt that those success stories go any farther than hypothetical pet projects with 2-3 technically proficient team members. The reality is that most game development teams consist in large part of people who don’t give a hoot about how Git works or how LFS fits into that, and just want to back up and share their work with minimal effort. I mean, I already had trouble explaining Subversion to some people, people who were otherwise very capable at their job. For now, Git + LFS just serves to make that whole process a lot harder.
The reason Perforce works so well for binary blobs, is that artists can LOCK a particular asset, so that other artists don’t edit it at the same time.
This is crucial for many kinds of workflows where there are frequent, distributed edits to binary assets, and git, being fully decentralized, can’t do this – it has no concept of “locking.”
Then again, Unreal could do wonders for improving the artist workflow on git by making sure all assets are text mode, and that files of types like JSON or XML actually includes newlines at the appropriate places (JSON: after each comma or right-brace; XML: after each close tag and before each open tag that directly follows another open tag.)
Maybe someone will add “git lock” as a git feature, and maybe that will be merged into git mainline, but I wouldn’t hold my breath…
Github, Gitlab, Bitbucket, and a few others now support file locking actually.