[forrestthewoods]

> However, I continue to be amazed that Perforce survived Git.

Virtually 100% of non-indie devs use Perforce.

Is Perforce good? Ehhh not really. It’s been stagnant for 15 years.

Is Git capable of meeting game dev needs? It’s not enough close. No Git LFS does not count.

Personally I think even Git is mediocre at best. But it’s all modern devs know. So there’s been very little progress towards version control that doesn’t suck. Very sad.

Hopefully Epic’s Lore is good. Low odds. But not zero! And hey at least they’re trying.

[lazypenguin]

Agreed, in my experience VCS still an unsolved problem for gaming. Git/SVN/Perforce are picked not because they’re the best but because there’s really nothing else. My team uses git for code and SVN for assets and it sort of sucks. I’m keeping an eye on lore and while it has great potential it’s still immature and under resourced (seems like side project at Epic from what insights I can gather)

[invader]

> Virtually 100% of non-indie devs use Perforce.

Not really. There are better products out there.

When I worked at Triple-A studio, we used Alienbrain, which is specifically tailored for huge binary versioning with previews and stuff. We had terabytes of assets, and Alienbrain handled it well, including seamless integration into pipelines - something a stock git or Perforce would never achieve.

[StilesCrisis]

Blizzard? I've never heard of Alienbrain used elsewhere.

[invader]

Not Blizzard. A French game developer and publisher that has been defunct for many years now. But even then, I remember talking to colleagues from other studios and many used Alienbrain - primarily for art assets. We used SVN and later git/mercurial for code.

Since Alienbrain was quite popular back then, I assume they are still around now. Given that git still has no out-of-the-box facilities to handle large binaries and asset previews conveniently.

[forrestthewoods]

Huh? Terabytes of assets is small scale by AAA standards.

Alienbrain has very minimal usage in comparison to perforce. Very minimal.

[dijit]

not sure why this is flagged, the accidental omission of “game” devs can’t be it. it’s extremely true that game devs either use perforce, or they’re trying to use SVN because their company is cheap… perforce is strictly superior to SVN and miles better than GitLFS- and they’ve been sitting on that fact for over a decade.

I think they must have some kind of patent protection because their software is buggy too.. i have no idea how this company can survive with what is, honestly, an unfinished product and a directionless, soulless and bloated organisation attached to it…

… but it is the industry standard in game dev and automotive …

what a lucky position to be in.

[traceroute66]

> i have no idea how this company can survive with what is, honestly, an unfinished product and a directionless, soulless and bloated organisation attached to it…

Some might say you could say that about Microsoft too. :)

[LtWorf]

No no. I know SVN and mercurial as well. Git is better. And normally when someone pushes a huge file it means they compiled something on their machine and are placing it on git, which is something that raises all the alarm bells for me.

[flohofwoe]

You want to have your original art files (before they enter the asset pipeline) in the VCS (photoshop images, 3d models, maybe even videos), basically *all* files associated with the game project. Those source asset files are usually in the 5..20 MByte range, and up to 100 MByte isn't all that unusual either. Git (even with the LFS crutch) completely breaks down in such a scenario because it was designed for handling mainly text (while in game dev projects at most 1..5% of all source data is text (by number of files, several orders of magnitude less by size). Even good ole SVN is much better in that scenario than git (assuming you run SVN on a big, dedicated inhouse server).

[rcxdude]

Except in game dev where you want to version control your art assets as well.

[LtWorf]

I was responding to someone who made a generic statement about git?

[dijit]

it does kind of suck though. (and he was talking about gamedev, which is not the only kind of development that deals with more than just plaintext, but its the one you can probably understand best).

Git solves a problem that we immediately unsolve constantly, and so we end up with the warts of both.

Its so ubiquitous though that people literally can’t even step back and realise this fact unless they are forcefully exposed to other paradigms (which they fight against the whole time).

Theres a lot of psychology to be learned here, its not sunk cost fallacy, its something deeper than that. Like rewiring the brain, even for a simpler paradigm, is almost painful for people.

How can you even know whats better if your brain is wired to know Git and distributed version control (yet not distributed)? It’s like imagining what it would feel like to smell electrical currents, the brain isn’t wired to know it.

[LtWorf]

Ok but how should the improved git replacement actually be?

Feels to me you're just saying things.

[dijit]

Obviously you feel that way, thats my entire point.

Try alternatives, they already exist.

[Kwpolska]

Pretty sure you're responding to someone talking about game development.

[rcxdude]

I mean, in general, the fact the git doesn't deal with large files well is not really a feature, even if it incidentally makes it a worse idea to check build artifacts into your repo.

[LtWorf]

I don't think it's large files. It's basically made for .txt files and that is all. Even small binary files… you can have them but it's not great with those.

I think it's fine for scope to exist.

[ChrisMarshallNY]

> Virtually 100% of non-indie GAME devs use Perforce.

FTFY. Git is likely the system used by almost every non game pro shop out there. Paranoid ones self-host.

Linus changed the world twice, and Git may have more impact, overall, than Linux (arguably).

Not bad, for a 10-day yak-shave project.

[pjmlp]

Which would have failed had it been developed by someone else, without being a requirement for Linux kernel development.

[zorked]

The Linux kernel adopted Bitkeeper before git and it never spread out from there. It's not that many people working on the kernel.

git growth was very symbiotic with GitHub growth. I don't remember why GitHub became popular in the first place. I think it was the Ruby community? GitHub was one of their own during an explosion of Ruby on Rails and successful startups using it.

[pjmlp]

Sure, if we ignore Bit keeper was commercial, always a hot topic, and not developed by Linus.

[cataphract]

Yeah, for a while it was not clear that git would win over mercurial. GitHub was decisive.

[rtpg]

Maybe? But this is an argument you can make about most technology adoption (silly recent example: USB-C adoption obviously buffetted by Apple showing up and saying "it's all this now" and having a bunch of people willing to swap everything out for it)

[pjmlp]

The same Apple that was forced by EU regulators to actually adopt it across their devices?

[ChrisMarshallNY]

Yup. That doesn’t change the effect, though.

That kind of thing has happened before. When HP adopted IEE-488, it became the standard test equipment interface for a couple of decades.

USBC has arrived.

[pjmlp]

Yes it does, otherwise people in Europe would still not use USB C on their Apple gear for the most part.

[ChrisMarshallNY]

Agreed.

The thing about an SCM, though, is that it needs to be rock-solid reliable and trustworthy. No "YOLO, Bro!" or "Move Fast and Break Things."

Git is that. I believe that this is exactly because of who wrote it.

Torvalds has plenty of detractors (and they aren't necessarily wrong), but he is one hell of a C programmer.

I'd trust stuff he wrote, over about 95% of what modern devs, do, these days.