> People should use the VCS that's appropriate for their project rather than insist on git everywhere.

A lot of people don't seem to realise this. I work in game dev and SVN or Perforce are far far better than Git for source control in this space.

In AA game dev a checkout (not the complete history, not the source art files) can easily get to 300GB of binary data. This is really pushing Subversion to it's limits.

In AAA gamedev you are looking at a full checkout of the latest assets (not the complete history, not the source art files) of at least 1TB and 2TB is becoming more and more common. The whole repo can easily come in at 100 TB. At this scale Perforce is really the only game in town (and they know this and charge through the nose for it).

In the movie industry you can multiply AAA gamedev by ~10.

Git has no hope of working at this scale as much as I'd like it to.

▲

jayd16 5 days ago | parent | next [-]

Perforce gets the job done but it's a major reason why build tooling is worse in games.

Github/gitlab is miles ahead of anything you can get with Perforce. People are not just pushing for git because they ux of it, they're pushing git so they can use the ecosystem.

▲

bananaboy 4 days ago | parent [-]

What do you mean “build tooling is worse in games”? I’ve worked in games for 20 years and used both perforce and got extensively across small, medium, and large projects.

There’s nothing technically worse about perforce with regard to CI/CD, if that’s what you’re talking about, except that of course there are more options for git where you just click a button and enter your credentials and away you go. But that’s more a function of the fact that there aren’t as many options for perforce hosting and companies are more likely to host it internally themselves.

If companies are using perforce but aren’t running any CI/CD that’s because they’re lazy/small/don’t see the value.

▲

jayd16 4 days ago | parent [-]

You said it yourself, there are less options and that's worse. Swarm is a bad joke. Nothing is as integrated as gitlab/GitHub.

	▲	bananaboy 4 days ago \| parent \| next [-]
		Right. Sure I agree with that. You have to do a lot more yourself. I just don't think it's that big a deal though but that's probably just me. Someone running Perforce has probably set that up themselves, and so they vaguely know what they're doing. So if they care about CI/CD they probably have the ability to set it up themselves. Personally I've used CruiseControl.NET, Jenkins, Buildbot, and custom in-house software and the first three support Perforce out of the box. I also don't mind the classic Swarm UI (I don't like the new UI) although I admit I do prefer the GitHub and GitLab UI!
	▲	dazzawazza 4 days ago \| parent \| prev [-]
		There is the old adage that every bit of friction increases the chance something won't be done. Swarm feels like a minimal effort to me and just isn't as frictionless as GitHub. Id rather have Swarm than not, but it's not great.

▲

gmokki 5 days ago | parent | prev [-]

I've been thinking of using git filter to split the huge asset files (that are just internally a collection of assets bundler to 200M-1GB files) into smaller ones. That way when artist modifies one sub-asset in a huge file only the small change is recorded in history. There is an example filter for doing this with zip files.

The above should work. But does git support multiple filters for a file? For example first the above asset split filter and then store the files in LFS which is another filter.

	▲	dazzawazza 5 days ago \| parent [-]
		I mean it might work but you'll still get pull time-outs constantly with LFS. It's expensive to wait two or three days before you can start working on a project. Go way for two weeks, it will be a day before you can "pulled" up to date. I hope this "new" system works but I think Perforce is safe for now.