3 ms·

Yes, that’s pretty much the case! Same here, Perforce has advantages for binaries, but there is some internal tooling, Python based, which will benefit from Git

Yes, that’s pretty much the case! Same here, Perforce has advantages for binaries, but there is some internal tooling, Python based, which will benefit from Git.

gumby 4y ago
Would it benefit from not being in the same system as everything else?
- lastdong 4y ago
  Apologies, missed your comment… Basically the overhead of creating and managing repos on gitlab is currently less complex, organizational speaking. but it is a fair question and maybe processes need to be improved to enable other scenarios.
lifthrasiir 4y ago
> [...] there is some internal tooling, Python based, which will benefit from Git. Do not speculate; quantify it. The switch to Git will affect the whole team, your proposal should be as complete as possible. My last workplace---also in the gaming industry---once used a mix of Git and Perforce, but now exclusively uses Git. This was not a light decision, artists and client programmers preferred Perforce for a good reason and using both Git and Perforce did work albeit with caveats (we had lots of tooling to synchronize both repos for example). But engine and server programmers also did have a good reason to use Git, especially because they did a full code review and relied on fast branching. So we developed a simple graphical interface to Git LFS for artists and client programmers, which finally made the switch viable. If we didn't have such interface and forced Git for everyone it wouldn't have worked at all. (To be fair, some still complain and it is an ongoing challenge to maintain the interface though. My very last job in that company was working around a bug in Gitlab's handling of Git LFS.)
- gumby 4y ago
  > So we developed a simple graphical interface to Git LFS for artists and client programmers, which finally made the switch viable...To be fair, some still complain and it is an ongoing challenge to maintain the interface though. Wow. My experience is that it wasn't worth the hassle of trying to make this change. Actually the other way (standardizing on Perforce) would have been a major hassle too. At a prior job where we confronted this we had Perforce (game and some other host code), git (various low level stuff like kernel) and whatever the cad guys used. And google docs which of course have a painful and vestigial versioning system. In that case we had bigger fish to fry than the data control systems.
  - lifthrasiir 4y ago
    How did you synchronize all the things? I think it'd be the single biggest factor; if you don't have to synchronize them frequently, or you have a brilliant way to synchronize them without relying on repos, multiple repos can indeed coexist. In my case however this resulted in lots of problems even when we had out-of-band tooling.
    - gumby 4y ago
      It was a nightmare; the only saving grace was that team was small enough that everybody could talk to everybody else. We might have been able to eliminate Perforce (though there was one particularly cantakerous game dev) but then we'd still have the CAD data issues, so I threw in the towel on this problem. Oh, I should be clear: I didn't mean "synchronize" in that code went back and forth between control systems, if that's what you meant. Device code (kernel, drivers, etc) was in git and stayed there; game code and assets were in Perforce and stayed there; and CAD stuff was in whatever that system was. And we never had good document control as we used (ugh) google docs and text files in the various repos.

Yes, that’s pretty much the case! Same here, Perforce has advantages for binaries, but there is some internal tooling, Python based, which will benefit from Git.

gumby 4y ago

Would it benefit from not being in the same system as everything else?

lastdong 4y ago
Apologies, missed your comment… Basically the overhead of creating and managing repos on gitlab is currently less complex, organizational speaking. but it is a fair question and maybe processes need to be improved to enable other scenarios.

lifthrasiir 4y ago

> [...] there is some internal tooling, Python based, which will benefit from Git. Do not speculate; quantify it. The switch to Git will affect the whole team, your proposal should be as complete as possible. My last workplace---also in the gaming industry---once used a mix of Git and Perforce, but now exclusively uses Git. This was not a light decision, artists and client programmers preferred Perforce for a good reason and using both Git and Perforce did work albeit with caveats (we had lots of tooling to synchronize both repos for example). But engine and server programmers also did have a good reason to use Git, especially because they did a full code review and relied on fast branching. So we developed a simple graphical interface to Git LFS for artists and client programmers, which finally made the switch viable. If we didn't have such interface and forced Git for everyone it wouldn't have worked at all. (To be fair, some still complain and it is an ongoing challenge to maintain the interface though. My very last job in that company was working around a bug in Gitlab's handling of Git LFS.)

gumby 4y ago
> So we developed a simple graphical interface to Git LFS for artists and client programmers, which finally made the switch viable...To be fair, some still complain and it is an ongoing challenge to maintain the interface though. Wow. My experience is that it wasn't worth the hassle of trying to make this change. Actually the other way (standardizing on Perforce) would have been a major hassle too. At a prior job where we confronted this we had Perforce (game and some other host code), git (various low level stuff like kernel) and whatever the cad guys used. And google docs which of course have a painful and vestigial versioning system. In that case we had bigger fish to fry than the data control systems.
- lifthrasiir 4y ago
  How did you synchronize all the things? I think it'd be the single biggest factor; if you don't have to synchronize them frequently, or you have a brilliant way to synchronize them without relying on repos, multiple repos can indeed coexist. In my case however this resulted in lots of problems even when we had out-of-band tooling.
  - gumby 4y ago
    It was a nightmare; the only saving grace was that team was small enough that everybody could talk to everybody else. We might have been able to eliminate Perforce (though there was one particularly cantakerous game dev) but then we'd still have the CAD data issues, so I threw in the towel on this problem. Oh, I should be clear: I didn't mean "synchronize" in that code went back and forth between control systems, if that's what you meant. Device code (kernel, drivers, etc) was in git and stayed there; game code and assets were in Perforce and stayed there; and CAD stuff was in whatever that system was. And we never had good document control as we used (ugh) google docs and text files in the various repos.