5 ms·

But they surely don't use git for that, right? In scenarios like this a versioning system that does not track all history locally would be a better fit.

by kahoon 12y ago

stonemetal 12y ago
Perforce tends to be big in game dev because it does better with repos full of giant blobs, has locking for working with them etc.
eropple 12y ago
Perforce is king in game development. It's also the only place I personally still use Subversion.
efraim 12y ago
I think most use Perforce.
rl3 12y ago
As the other replies say, Perforce is dominant in commercial game development. However, Perforce does have Git integration now, allowing for either a centralized or distributed version control model. Considering the popularity of Git, I wouldn't doubt smaller Perforce-based game projects are going the DVCS route. Also, hypothetically speaking, consider if you had a game project that would eventually grow to 1-2TB in repository size. If you spent $100 per developer to augment each of their workstations with a dedicated 3TB hard drive, you would have an awesome level of redundancy using DVCS (plus all the other advantages). I know it's no replacement for cold, off-site backups, but it would still be nice.
Peaker 12y ago
It could use git-annex[1]? [1] https://git-annex.branchable.com/ https://git-annex.branchable.com/
- kyrra 12y ago
  There are a lot of non developers using source control for game development. Perforce makes it easier for graphic designers and the like to use the VCS and not have to deal with a CLI. Perforce just handles binary blobs well.
- yepguy 12y ago
  Strange as it sounds, git-annex doesn't really do file versioning very well.
  - asdfaoeu 12y ago
    Are you talking about git annex assistant or git annex? git annex does file versioning very nicely then again it doesn't work on Windows so that's probably not very useful for most game developers.
    - eropple 12y ago
      git-annex does file versioning, but it's extremely uncomfortable to use (and I say this as somebody totally comfortable with git) and I'd never expect an artist or other only-semi-technical person to use it even if it worked with Windows. Especially when Subversion or Perforce are right there.
eridius 12y ago
Git does have support for "shallow" clones, that don't pull down the full history but only the recent history.
- greggman 12y ago
  shallow clones the only issue for games. Another problem is, unlike code, art assets usually can't be merged. You can't merge 2 photoshop texture files or 2 edits to a 3d character made in Maya. So, you need some central system to manage the assets so that people know "hey, don't edit this file right now because so-and-so is editing it". Ideally you'd like to know this BEFORE you start editing. In other words, you don't want to spent 15-60 minutes editing something and only on saving or trying to check in get told "hey, sorry but someone else was editing this file so you'll have to discard your changes and start over". Some editors are better at this than others. You could try to write something on outside of git to help with this but why when P4 already provides this?
  - nawitus 12y ago
    Even better would be collaborative real-time editing.
  - eridius 12y ago
    > You could try to write something on outside of git to help with this but why when P4 already provides this? Maybe because P4 is kind of a PITA? I used it for 10 months on a project (without any noticeable art assets, even; this was just code) and it regularly caused problems. The company had someone whose sole job was to administrate P4, and it was sorely needed. Of course, it's been many years, and I no longer remember details about the precise problems encountered, just the overall frustration. Although the one thing I do remember is the aggravation caused when a coworker accidentally locked a file they weren't editing and then left for the day.

But they surely don't use git for that, right? In scenarios like this a versioning system that does not track all history locally would be a better fit.

by kahoon 12y ago

But they surely don't use git for that, right? In scenarios like this a versioning system that does not track all history locally would be a better fit.

stonemetal 12y ago

Perforce tends to be big in game dev because it does better with repos full of giant blobs, has locking for working with them etc.

eropple 12y ago

Perforce is king in game development. It's also the only place I personally still use Subversion.

efraim 12y ago

I think most use Perforce.

rl3 12y ago

As the other replies say, Perforce is dominant in commercial game development. However, Perforce does have Git integration now, allowing for either a centralized or distributed version control model. Considering the popularity of Git, I wouldn't doubt smaller Perforce-based game projects are going the DVCS route. Also, hypothetically speaking, consider if you had a game project that would eventually grow to 1-2TB in repository size. If you spent $100 per developer to augment each of their workstations with a dedicated 3TB hard drive, you would have an awesome level of redundancy using DVCS (plus all the other advantages). I know it's no replacement for cold, off-site backups, but it would still be nice.

Peaker 12y ago

It could use git-annex[1]? [1] https://git-annex.branchable.com/ https://git-annex.branchable.com/

kyrra 12y ago
There are a lot of non developers using source control for game development. Perforce makes it easier for graphic designers and the like to use the VCS and not have to deal with a CLI. Perforce just handles binary blobs well.
yepguy 12y ago
Strange as it sounds, git-annex doesn't really do file versioning very well.
- asdfaoeu 12y ago
  Are you talking about git annex assistant or git annex? git annex does file versioning very nicely then again it doesn't work on Windows so that's probably not very useful for most game developers.
  - eropple 12y ago
    git-annex does file versioning, but it's extremely uncomfortable to use (and I say this as somebody totally comfortable with git) and I'd never expect an artist or other only-semi-technical person to use it even if it worked with Windows. Especially when Subversion or Perforce are right there.

eridius 12y ago

Git does have support for "shallow" clones, that don't pull down the full history but only the recent history.

greggman 12y ago
shallow clones the only issue for games. Another problem is, unlike code, art assets usually can't be merged. You can't merge 2 photoshop texture files or 2 edits to a 3d character made in Maya. So, you need some central system to manage the assets so that people know "hey, don't edit this file right now because so-and-so is editing it". Ideally you'd like to know this BEFORE you start editing. In other words, you don't want to spent 15-60 minutes editing something and only on saving or trying to check in get told "hey, sorry but someone else was editing this file so you'll have to discard your changes and start over". Some editors are better at this than others. You could try to write something on outside of git to help with this but why when P4 already provides this?
- nawitus 12y ago
  Even better would be collaborative real-time editing.
- eridius 12y ago
  > You could try to write something on outside of git to help with this but why when P4 already provides this? Maybe because P4 is kind of a PITA? I used it for 10 months on a project (without any noticeable art assets, even; this was just code) and it regularly caused problems. The company had someone whose sole job was to administrate P4, and it was sorely needed. Of course, it's been many years, and I no longer remember details about the precise problems encountered, just the overall frustration. Although the one thing I do remember is the aggravation caused when a coworker accidentally locked a file they weren't editing and then left for the day.