6 ms·

I wasn't able to find an open source alternative to Newrelic APM for ruby. Perforce is also something that's very useful for game development but relatively ex

by thexa4 7y ago

I wasn't able to find an open source alternative to Newrelic APM for ruby. Perforce is also something that's very useful for game development but relatively expensive.

safwan 7y ago
That is really True. The APM world does not have any good open source alternative, Elastic APM is ok, but I think it is open core, not open source. Sentry is trying to build one, but maybe that will not be also OSI approved license.
billconan 7y ago
Why’s perforce not replaceable by git?
- thexa4 7y ago
  From what I've seen, perforce is better for storing binary intermediates. Git doesn't work very well with partial or subfolder checkouts which is something you would need if you want to store intermediates. In games intermediates can take multiple hours to build (like maps). Building the game from scratch every commit like it's usually done with git CI tooling does not work very well. We also ran into wanting to give modders access to maps and materials but not to game code.
- cweagans 7y ago
  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.

by thexa4 7y ago

I wasn't able to find an open source alternative to Newrelic APM for ruby. Perforce is also something that's very useful for game development but relatively expensive.

safwan 7y ago

That is really True. The APM world does not have any good open source alternative, Elastic APM is ok, but I think it is open core, not open source. Sentry is trying to build one, but maybe that will not be also OSI approved license.

billconan 7y ago

Why’s perforce not replaceable by git?

thexa4 7y ago
From what I've seen, perforce is better for storing binary intermediates. Git doesn't work very well with partial or subfolder checkouts which is something you would need if you want to store intermediates. In games intermediates can take multiple hours to build (like maps). Building the game from scratch every commit like it's usually done with git CI tooling does not work very well. We also ran into wanting to give modders access to maps and materials but not to game code.
cweagans 7y ago
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.