| ▲ | ChrisMarshallNY a day ago |
| If you are using Perforce as an enterprise system, $500 is peanuts. Perforce can get pricey. We used to be a Perforce shop, in my last job. However, I continue to be amazed that Perforce survived Git. I assume its ability to handle large binaries has been what saved it. I seem to remember an HN posting, some time ago, about a new system, aimed at creatives, and that handles big binaries. It looked fairly good, but not sure how it’s doing. |
|
| ▲ | a-dub a day ago | parent | next [-] |
| > If you are using Perforce as an enterprise system, $500 is peanuts. Perforce can get pricey. i think it was $600/seat back when i paid attention (20+ years ago). don't remember if it was perpetual or annual. > However, I continue to be amazed that Perforce survived Git. I assume its ability to handle large binaries has been what saved it. yeah i think it lives on in games probably mostly through inertia. last i looked the company itself had shifted away from p4 classic to some git wrapper stuff. i've never actually seen it but my understanding is that google's custom internal system (piper) basically is a reimplemented scalable p4+g4 wrapper. i always thought the workspace mapping and workspace template model in p4 was pretty elegant, especially for things like embedded platforms where you could opt in and out various subtrees which made very large device trees/bsps more manageable. also they were the first widely deployed vcs system that attempted to be efficient (server side indices for local tree state and communication with the server in deltas rather than forcing complete rescans for every operation that often involved talking to the server as each file was scanned) |
|
| ▲ | khurs a day ago | parent | prev | next [-] |
| >I seem to remember an HN posting, some time ago... Was 31 days ago... and it's Epic backed rather than a sole indie dev so likely to mature. https://news.ycombinator.com/item?id=48571081 |
|
| ▲ | blagie a day ago | parent | prev | next [-] |
| > However, I continue to be amazed that Perforce survived Git. I assume its ability to handle large binaries has been what saved it. Curiously enough, the git data model is ideal for handling large binaries. The place it crashes-and-burns is the user space. |
|
| ▲ | nylonstrung a day ago | parent | prev | next [-] |
| You're probably thinking of Lore by Epic Games which was announced recently and seems to be well-received so far and natively supported by Unreal Engine |
| |
| ▲ | ChrisMarshallNY a day ago | parent [-] | | Yup. That’s it. I remember when one of the engines (either Unreal or Unity), shipped with Perforce included. | | |
|
|
| ▲ | jordand a day ago | parent | prev | next [-] |
| Yeah there's no good alternative Version Control right now that can handle large binaries. And for Lore from Epic Games, while it's still 2-3 years away from being suitable for Game productions to replace Perforce, there's genuine interest and excitement about using/testing it (in some cases, studios are spending tens of thousands on P4 licenses they don't really want).
Lore is already used at scale in UEFN across a huge user base so the core tech behind it is solid and trusted. |
| |
| ▲ | sam_lowry_ a day ago | parent [-] | | git lfs? | | |
| ▲ | ChrisMarshallNY a day ago | parent [-] | | From what I understand (I don't use it, myself, so this is hearsay), Git LFS is unsuitable for the kinds of assets used by creative studios. | | |
| ▲ | Ferret7446 14 hours ago | parent | next [-] | | From what I understand, it's a tooling problem and not a technical issue with Git. By default Git only supports text diffs but that is not a fundamental constraint of the architecture. Actually Git deals with binary blobs and the diffs are a UI porcelain layer. Binary diffs could be added on top with just a SMOP | |
| ▲ | gregschoeninger a day ago | parent | prev [-] | | We've been working for a few years on a VCS that is starting to get adopted by creative studios - called "Oxen" It's open source: https://github.com/oxen-AI/oxen Most users are building their own interface on top, but we also have a nice experience in our web ui: https://oxen.ai Would love people to try it out and give us feedback! |
|
|
|
|
| ▲ | aitchnyu a day ago | parent | prev | next [-] |
| Feels like a captive audience. My tiny company paid a buggy Github competitor even in 2019 and they hiked prices like crazy. They did have a brand new project that deployed multiple projects to our own VPS with zero downtime. |
|
| ▲ | forrestthewoods a day ago | parent | prev | next [-] |
| > However, I continue to be amazed that Perforce survived Git. Virtually 100% of non-indie devs use Perforce. Is Perforce good? Ehhh not really. It’s been stagnant for 15 years. Is Git capable of meeting game dev needs? It’s not enough close. No Git LFS does not count. Personally I think even Git is mediocre at best. But it’s all modern devs know. So there’s been very little progress towards version control that doesn’t suck. Very sad. Hopefully Epic’s Lore is good. Low odds. But not zero! And hey at least they’re trying. |
| |
| ▲ | lazypenguin a day ago | parent | next [-] | | Agreed, in my experience VCS still an unsolved problem for gaming. Git/SVN/Perforce are picked not because they’re the best but because there’s really nothing else. My team uses git for code and SVN for assets and it sort of sucks. I’m keeping an eye on lore and while it has great potential it’s still immature and under resourced (seems like side project at Epic from what insights I can gather) | |
| ▲ | invader a day ago | parent | prev | next [-] | | > Virtually 100% of non-indie devs use Perforce. Not really. There are better products out there. When I worked at Triple-A studio, we used Alienbrain, which is specifically tailored for huge binary versioning with previews and stuff. We had terabytes of assets, and Alienbrain handled it well, including seamless integration into pipelines - something a stock git or Perforce would never achieve. | | |
| ▲ | StilesCrisis a day ago | parent [-] | | Blizzard? I've never heard of Alienbrain used elsewhere. | | |
| ▲ | invader 6 hours ago | parent [-] | | Not Blizzard. A French game developer and publisher that has been defunct for many years now. But even then, I remember talking to colleagues from other studios and many used Alienbrain - primarily for art assets. We used SVN and later git/mercurial for code. Since Alienbrain was quite popular back then, I assume they are still around now. Given that git still has no out-of-the-box facilities to handle large binaries and asset previews conveniently. |
|
| |
| ▲ | dijit a day ago | parent | prev | next [-] | | not sure why this is flagged, the accidental omission of “game” devs can’t be it. it’s extremely true that game devs either use perforce, or they’re trying to use SVN because their company is cheap… perforce is strictly superior to SVN and miles better than GitLFS- and they’ve been sitting on that fact for over a decade. I think they must have some kind of patent protection because their software is buggy too.. i have no idea how this company can survive with what is, honestly, an unfinished product and a directionless, soulless and bloated organisation attached to it… … but it is the industry standard in game dev and automotive … what a lucky position to be in. | | |
| ▲ | traceroute66 a day ago | parent [-] | | > i have no idea how this company can survive with what is, honestly, an unfinished product and a directionless, soulless and bloated organisation attached to it… Some might say you could say that about Microsoft too. :) |
| |
| ▲ | LtWorf a day ago | parent | prev | next [-] | | No no. I know SVN and mercurial as well. Git is better. And normally when someone pushes a huge file it means they compiled something on their machine and are placing it on git, which is something that raises all the alarm bells for me. | | |
| ▲ | flohofwoe a day ago | parent | next [-] | | You want to have your original art files (before they enter the asset pipeline) in the VCS (photoshop images, 3d models, maybe even videos), basically *all* files associated with the game project. Those source asset files are usually in the 5..20 MByte range, and up to 100 MByte isn't all that unusual either. Git (even with the LFS crutch) completely breaks down in such a scenario because it was designed for handling mainly text (while in game dev projects at most 1..5% of all source data is text (by number of files, several orders of magnitude less by size). Even good ole SVN is much better in that scenario than git (assuming you run SVN on a big, dedicated inhouse server). | |
| ▲ | rcxdude a day ago | parent | prev [-] | | Except in game dev where you want to version control your art assets as well. | | |
| ▲ | LtWorf a day ago | parent [-] | | I was responding to someone who made a generic statement about git? | | |
| ▲ | dijit a day ago | parent | next [-] | | it does kind of suck though. (and he was talking about gamedev, which is not the only kind of development that deals with more than just plaintext, but its the one you can probably understand best). Git solves a problem that we immediately unsolve constantly, and so we end up with the warts of both. Its so ubiquitous though that people literally can’t even step back and realise this fact unless they are forcefully exposed to other paradigms (which they fight against the whole time). Theres a lot of psychology to be learned here, its not sunk cost fallacy, its something deeper than that. Like rewiring the brain, even for a simpler paradigm, is almost painful for people. How can you even know whats better if your brain is wired to know Git and distributed version control (yet not distributed)? It’s like imagining what it would feel like to smell electrical currents, the brain isn’t wired to know it. | | |
| ▲ | LtWorf a day ago | parent [-] | | Ok but how should the improved git replacement actually be? Feels to me you're just saying things. | | |
| ▲ | dijit a day ago | parent [-] | | Obviously you feel that way, thats my entire point. Try alternatives, they already exist. | | |
| ▲ | LtWorf 21 hours ago | parent [-] | | Can you name one free alternative that already exists and is better? | | |
| ▲ | dijit 20 hours ago | parent [-] | | Mercurial. Pijul. Darcs. and.. Perforce is free for 5 users too. ;) |
|
|
|
| |
| ▲ | Kwpolska a day ago | parent | prev | next [-] | | Pretty sure you're responding to someone talking about game development. | |
| ▲ | rcxdude a day ago | parent | prev [-] | | I mean, in general, the fact the git doesn't deal with large files well is not really a feature, even if it incidentally makes it a worse idea to check build artifacts into your repo. | | |
| ▲ | LtWorf a day ago | parent [-] | | I don't think it's large files. It's basically made for .txt files and that is all. Even small binary files… you can have them but it's not great with those. I think it's fine for scope to exist. |
|
|
|
| |
| ▲ | ChrisMarshallNY a day ago | parent | prev [-] | | > Virtually 100% of non-indie GAME devs use Perforce. FTFY. Git is likely the system used by almost every non game pro shop out there. Paranoid ones self-host. Linus changed the world twice, and Git may have more impact, overall, than Linux (arguably). Not bad, for a 10-day yak-shave project. | | |
| ▲ | pjmlp a day ago | parent [-] | | Which would have failed had it been developed by someone else, without being a requirement for Linux kernel development. | | |
| ▲ | zorked a day ago | parent | next [-] | | The Linux kernel adopted Bitkeeper before git and it never spread out from there. It's not that many people working on the kernel. git growth was very symbiotic with GitHub growth. I don't remember why GitHub became popular in the first place. I think it was the Ruby community? GitHub was one of their own during an explosion of Ruby on Rails and successful startups using it. | | |
| ▲ | pjmlp a day ago | parent | next [-] | | Sure, if we ignore Bit keeper was commercial, always a hot topic, and not developed by Linus. | |
| ▲ | cataphract a day ago | parent | prev | next [-] | | Yeah, for a while it was not clear that git would win over mercurial. GitHub was decisive. | |
| ▲ | redsocksfan45 a day ago | parent | prev [-] | | [dead] |
| |
| ▲ | rtpg a day ago | parent | prev [-] | | Maybe? But this is an argument you can make about most technology adoption (silly recent example: USB-C adoption obviously buffetted by Apple showing up and saying "it's all this now" and having a bunch of people willing to swap everything out for it) | | |
| ▲ | pjmlp a day ago | parent | next [-] | | The same Apple that was forced by EU regulators to actually adopt it across their devices? | | |
| ▲ | ChrisMarshallNY a day ago | parent [-] | | Yup. That doesn’t change the effect, though. That kind of thing has happened before. When HP adopted IEE-488, it became the standard test equipment interface for a couple of decades. USBC has arrived. | | |
| ▲ | pjmlp a day ago | parent [-] | | Yes it does, otherwise people in Europe would still not use USB C on their Apple gear for the most part. |
|
| |
| ▲ | ChrisMarshallNY a day ago | parent | prev [-] | | Agreed. The thing about an SCM, though, is that it needs to be rock-solid reliable and trustworthy. No "YOLO, Bro!" or "Move Fast and Break Things." Git is that. I believe that this is exactly because of who wrote it. Torvalds has plenty of detractors (and they aren't necessarily wrong), but he is one hell of a C programmer. I'd trust stuff he wrote, over about 95% of what modern devs, do, these days. |
|
|
|
|
|
| ▲ | momocowcow a day ago | parent | prev [-] |
| Im amazed git survived at all. Such a mess of complexity and exotic jargon to abstract away something that should be inherently simple. After 20 years I can use it with ease thanks to llms. |
| |
| ▲ | superb_dev a day ago | parent | next [-] | | I genuinely think you have to be trying to not pick up git after 20 years. Have a little more faith in yourself, it's not super complicated | |
| ▲ | ndriscoll a day ago | parent | prev | next [-] | | It is inherently simple? It's a couple tools to manipulate a graph of snapshots. You can make commits, checkout commits, make/move references to commits, diff commits, and apply diffs to commits. If you wrap your head around that you've pretty much mastered it. | |
| ▲ | pxmpxm a day ago | parent | prev | next [-] | | I love that comments like these incept million tech bro look-at-my-clout responses for having learned some subset of the magic incantations to make git barely usable... As if you get an award for mental heuristics to put up with a poorly architected product with leaky abstraction all over. If you mentions reflogs, i'm yelling bingo. Bonus points: You have 3 new commits and in one there is a change in file.stupid, how many git bs things does it take to revert file.stupid to previous version while keeping the rest of the change set. | | | |
| ▲ | Hendrikto a day ago | parent | prev | next [-] | | That just means you did not really try for 20 years. | | |
| ▲ | mrighele a day ago | parent | next [-] | | UI wise git sucks. The its commands are barely related to what they do, and that little makes sense only if you have in mind the underlying storage model (which is by itself a sign of bad UI). Almost any other version control tool I have used in my life make more sense that git. There are many reason for why git won, being able to use it without having to look up commands is not one of them. | | |
| ▲ | ndriscoll a day ago | parent [-] | | The commands don't require you to know the underlying storage model. e.g. I have maybe once in 15 years had an occasion to think about packfiles. I couldn't tell you basic facts about the storage like whether a git clone will mean you necessarily have the same object files as the upstream (I presume no). Content addressed (with named references) snapshots aren't the underlying storage model. They are the UI model, and they make a ton of sense for that purpose. |
| |
| ▲ | dijit a day ago | parent | prev [-] | | Come now, lets be real. How many esoteric tools are needed for proper development? “save my file” should not need a phd level awareness of the save model, yet it seems to because its so easy to fall off the happy path. | | |
| ▲ | tomsmeding a day ago | parent [-] | | It ought not to, indeed. However, if you want "save my file" to include awareness of other developers concurrently working on the same project -- even the same file -- with a decent way to handle conflicts, it suddenly becomes complicated. Git is probably not the optimal way of designing a UI around this, but it's not like this is an easy problem. | | |
| ▲ | dijit a day ago | parent [-] | | MINE | MERGED | THEIRS
where you can select elements from both and have them merge into the middle.Or the p4 merge way of: MINE | THEIRS
-------------
MERGED
Even most GUI's for git do it this way actually.Merging should not be a major issue, it should be a trivial annoyance. It shouldn't drop you into an interactive rebase that invalidates every object after it (necessarily). | | |
| ▲ | ndriscoll a day ago | parent [-] | | It doesn't "drop you into an interactive rebase" unless you tell it to. If you want to rebase, rebase. If you want to merge, merge. As you say, even most UIs for git show what you are saying you want. | | |
| ▲ | dijit a day ago | parent [-] | | you’re right, when a merge conflict happens it drops you in “detached head” and writes a diff into your files which even when modified away require you to issue a special command to continue. Its actually worse than interactive rebase. “detached head” and “rebase” aren’t meaningful verbs to normal people… when all you want is to save a working version | | |
| ▲ | ndriscoll a day ago | parent [-] | | Merge conflicts don't put you into a detached head state. You stay on the branch where you ran git merge. Why would it change your checked out branch? The special command is just `git add` to stage your changes followed by `git commit` (or do it all in one command as `git commit - a`), same as any other changes. Rebase is something else. It's something you do on purpose because you specifically want to rewrite the history. Personally I use it a lot and expect everyone on my team to, but you can use git just fine without ever rebasing or even knowing it's there. Like I actually have no idea what you're talking about. Is your criticism actually targeted at some specific UI tool that's not git? |
|
|
|
|
|
| |
| ▲ | redsocksfan45 a day ago | parent | prev [-] | | [dead] |
|