8 ms·

Perforce has a locking mechanism for files, which is important for the large binary objects that are used in game development. Git doesn't really have that conc

Perforce has a locking mechanism for files, which is important for the large binary objects that are used in game development. Git doesn't really have that concept, so it requires more out of band communication to make it work for that use case. Git LFS might handle this, but it's just not something that Perforce shops have to even think about, train their people on, etc. It's just "there" and there's somebody that they can call and yell at if things go wrong.

yellowapple 7y ago
> Git doesn't really have that concept Of locking files? Sure it does; if two people modify the same piece of code, then there will be a merge conflict, and whoever's doing the merge will have the opportunity to reconcile those two versions. It's like a lock, but you don't have to think about it / explicitly lock and unlock the object you're editing. Combine this with rebasing (git-speak for "switch to the branch into which I want to merge and then try applying all the changes from my branch") and you end up with a pretty coherent idea of what changed and in what order. Having used both branch-oriented (like Git) and locking-oriented (not Perforce specifically, but my current dayjob involves very similar version control schemes), I vastly prefer the former. Less ceremony around doing things in parallel, and less risk of development deadlocks (e.g. Alice locked A.cpp for editing, Bob locked B.dds for editing, Alice now wants to edit B.dds, Bob now wants to edit A.cpp, now Alice will have to revert her lock on A.cpp, wait for Bob to do everything he needs to do, then relock A.cpp and redo her changes all over again (probably also having to debug new things because of new bits and pieces Bob added) - or Bob will have to do so for B.dds - and cue fistfight in the breakroom). ---- That all being said, binary files are indeed a weak spot for Git, so if you really do want to version control your textures and models and sounds and such, then sure, perhaps a different VCS tailored for that use-case would be more ideal. In my experience, though, that tends to be an anti-pattern; generally better to keep code and assets separate (I'm well aware that tools/engines like e.g. Unity don't play the slightest bit nicely with that separation), using separate version control systems tailored to the specific content.
- domlebo70 7y ago
  Sometimes it is desirable to not have optimistic locking like git. Often you want to signal that you don't want a file/asset modified for a period.
  - yellowapple 7y ago
    I think we're gonna have to agree to disagree on that. I've found that locking a file from any changes entirely almost always causes more problems than it ostensibly solves, and is a massive impediment to productivity on any team larger than a single person. The vast majority of the time it's entirely unnecessary anyway.
    - domlebo70 7y ago
      Absolutely agree with you when it comes to textual/structural information where merge conflicts can be solved easily. But for binary like formats, I feel often there is no way to resolve a conflict.
    - joshuamorton 7y ago
      Yes, but you probably don't make a habit of storing music or video (or weird proprietary binary animation formats) that people are modifying in git.
      - yellowapple 7y ago
        Indeed I do not. If game developers (and/or game engine developers; looking at you, Unity3D...) showed similar restraint, then they likely wouldn't feel the need to tie themselves to 90's-esque version control schemes.
        pnako 7y ago
        The game industry has a completely different way of working compared to other tech fields. Most of their practices seem old fashioned, or anti-patterns, etc. if you look at them from an outside point of view. But they're trying to do something very hard: control both quality and deadline. It's not like an open source or enterprise IT project. The game has to be finished, good, by a given date. To do that they do many things, including slaughtering sacred cows about how things are supposed to be done. If hard locking saves them time by avoiding wasted efforts, by artists who are probably over-worked already, then what's the problem?

yellowapple 7y ago

> Git doesn't really have that concept Of locking files? Sure it does; if two people modify the same piece of code, then there will be a merge conflict, and whoever's doing the merge will have the opportunity to reconcile those two versions. It's like a lock, but you don't have to think about it / explicitly lock and unlock the object you're editing. Combine this with rebasing (git-speak for "switch to the branch into which I want to merge and then try applying all the changes from my branch") and you end up with a pretty coherent idea of what changed and in what order. Having used both branch-oriented (like Git) and locking-oriented (not Perforce specifically, but my current dayjob involves very similar version control schemes), I vastly prefer the former. Less ceremony around doing things in parallel, and less risk of development deadlocks (e.g. Alice locked A.cpp for editing, Bob locked B.dds for editing, Alice now wants to edit B.dds, Bob now wants to edit A.cpp, now Alice will have to revert her lock on A.cpp, wait for Bob to do everything he needs to do, then relock A.cpp and redo her changes all over again (probably also having to debug new things because of new bits and pieces Bob added) - or Bob will have to do so for B.dds - and cue fistfight in the breakroom). ---- That all being said, binary files are indeed a weak spot for Git, so if you really do want to version control your textures and models and sounds and such, then sure, perhaps a different VCS tailored for that use-case would be more ideal. In my experience, though, that tends to be an anti-pattern; generally better to keep code and assets separate (I'm well aware that tools/engines like e.g. Unity don't play the slightest bit nicely with that separation), using separate version control systems tailored to the specific content.

domlebo70 7y ago
Sometimes it is desirable to not have optimistic locking like git. Often you want to signal that you don't want a file/asset modified for a period.
- yellowapple 7y ago
  I think we're gonna have to agree to disagree on that. I've found that locking a file from any changes entirely almost always causes more problems than it ostensibly solves, and is a massive impediment to productivity on any team larger than a single person. The vast majority of the time it's entirely unnecessary anyway.
  - domlebo70 7y ago
    Absolutely agree with you when it comes to textual/structural information where merge conflicts can be solved easily. But for binary like formats, I feel often there is no way to resolve a conflict.
  - joshuamorton 7y ago
    Yes, but you probably don't make a habit of storing music or video (or weird proprietary binary animation formats) that people are modifying in git.
    - yellowapple 7y ago
      Indeed I do not. If game developers (and/or game engine developers; looking at you, Unity3D...) showed similar restraint, then they likely wouldn't feel the need to tie themselves to 90's-esque version control schemes.
      - pnako 7y ago
        The game industry has a completely different way of working compared to other tech fields. Most of their practices seem old fashioned, or anti-patterns, etc. if you look at them from an outside point of view. But they're trying to do something very hard: control both quality and deadline. It's not like an open source or enterprise IT project. The game has to be finished, good, by a given date. To do that they do many things, including slaughtering sacred cows about how things are supposed to be done. If hard locking saves them time by avoiding wasted efforts, by artists who are probably over-worked already, then what's the problem?