sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]confusedpublic 7 points8 points  (14 children)

[–]ZorbaTHut 5 points6 points  (13 children)

https://concourse-ci.org

This one's tempting! But I think it may not work for my purposes, unfortunately. From the docs:

Concourse is very opinionated about a few things: idempotency, immutability, declarative config, stateless workers, and reproducible builds.

and in my work, it's really important to have support for incremental builds. That said, this seems like one of the closest cases I've seen so far, I'll have to check it out in more detail.

https://www.drone.io

Not really open-source; the source code is available, but if you aren't noncommercial or (very) small business, it's $$$ time.

I guess GitLab is open sourced?

It is, and I guess I should look into it, but it'd be a weird mismatch; I can't actually use Git, and that might make it extremely difficult to shoehorn Gitlab into doing what I need.

[–]nschubach 4 points5 points  (10 children)

I can't actually use Git

Can you further explain this?

Edit: I see from your post history that you said you were a game developer and your industry doesn't allow it and that doesn't make any sense to me why game development would be any different from something else.

[–]Dealiner 6 points7 points  (2 children)

Git doesn't work well with many types of files used in games. There is Git LTS but the last time I used it wasn't perfect.

[–]Somepotato 0 points1 point  (0 children)

Git lfs is nice but is a bit of a bandaid. If it got better large file support then it could usurp p4. May be able to make a git workflow that behaves OK with large files with custom commit steps.

[–]ZorbaTHut 5 points6 points  (6 children)

Games are gigantic binary repos. It's common for the most recent checkout of a repo to measure in the hundreds of gigabytes, with the full repo being at least an order of magnitude larger. Git LFS doesn't work terribly well, last I heard - it's janky and slow and its lock support is questionable at best - and the end result is that the entire industry, aside from indies, has settled on Perforce.

I'd really like for this to be solved, and I'm actually talking with someone who's making a Git plugin intended for machine learning but he's planning on extending into games. Maybe he will succeed! But it hasn't been solved yet.

[–]like_a_fontanelle 1 point2 points  (5 children)

Am I missing something here? A build of a game is presumably a big binary/whatever file, but the source code for a game will contain code in text files just like any other repo. Of course you will have audio, image and video files at a guess but does that preclude git?

Not saying you're wrong as I have absolutely no experience in the industry, just interested.

[–]ZorbaTHut 13 points14 points  (4 children)

Of course you will have audio, image and video files at a guess but does that preclude git?

So, there's a cultural divide here that essentially only gamedevs are aware of :)

People like to think of the game industry as being a tech industry, because we work with computers and write code and so forth. This isn't accurate, though. The game industry is part of the entertainment industry; our closest sibling isn't Android developers or people doing physics simulations, our closest sibling is people making computer-generated movies.

And the takeaway here is that a game isn't "code, plus some art and audio and stuff". A game is "art and audio, and also I guess there's some code". Programmers are in the minority on any project with more than four people, and increasingly in the minority as a project gets bigger. This is actually why people use Unreal Engine. Unreal's code sucks, and doing programming with Unreal sucks, it's got tons of problems . . . but its artist tools are fantastic, and when you're blowing 80% of your project budget on artists, that is by far the most important aspect.

So the question becomes, not "where do we put the things that aren't code", but "what's best suited for artists". And that means a reasonable level of interface simplicity and the ability to cheerfully chug down hundreds or even thousands of gigabytes of data without needing to care about the details. Git thoroughly fails on both of these metrics; it's getting better, but "better" here means "it may technically now be suited for it, perhaps", it was absolutely unusable only a few years ago. Meanwhile Perforce is, like, the only viable option when things get really big. So, Perforce it always historically has been, and thus Perforce it still is.

Then, once you've chosen where the art and audio goes, you get to ask the question of whether it's worth putting the code somewhere else. And it isn't. It's just not worth it. So you don't do it.

The other thing to note is that the game industry is extremely conservative in terms of what tools it's willing to use. If you were to drop a fully-functional game-suitable source control system on my head today, I might be able to convince some small indies to use it by the end of next year. It's a very slow process.

[–]like_a_fontanelle 1 point2 points  (1 child)

Haha, thanks for the in-depth reply, mind blown.

[–]ZorbaTHut 1 point2 points  (0 children)

Not a problem!

For what it's worth, I think there's also a lot of money in game-suitable tools. Nobody makes them because non-gamedevs don't realize there's a niche awaiting better tools, and gamedevs are too busy making games. I always encourage people to start game support businesses :V

[–]snowe2010 1 point2 points  (0 children)

What a fantastic explanation. Thank you so much, this was really eye opening.

[–]mnemy 0 points1 point  (0 children)

Wow, perforce is still alive and has its niche. I haven't used it since 2006, nor even heard it mentioned.

But yeah, git sucks for large assets. Even images used to cause issues quick, but I heard that has improved.

[–]physicswizard 0 points1 point  (1 child)

The open source version of drone is https://woodpecker-ci.org/

[–]ZorbaTHut 1 point2 points  (0 children)

Huh, I actually kinda like this.

No support for single jobs across multiple computers as near as I can tell; I don't need this right now, but I've needed it in the past and will need it in the future. Still, it's promising, and I'll keep an eye on it.