Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Their docs seem entirely LLM written. It seems especially obvious in the FAQ. While I'm not against using LLMs for writing assistance, they've left a lot of the unnecessary language and typical stylistic choices in there, which erodes my trust in the project a bit. Perhaps it's a very good game-oriented version control system, but the lack of human attention on the docs makes me wonder how much they careby interpol_p
- Yeah, I hope I'm wrong, but it feels a little bit like "planned project no longer has internal support, let's see if we can make it open-source to garner goodwill and recoup some of our investment." Which isn't the worst thing that can happen.by fwip
- Yeah, I agree about the docs. I started on the system design page and my head started to swim after about 5 minutes. So exhausting to read!
On the flip side, I expect the project itself will be workable - well, assuming they're actually using it themselves! UE is a big pile of Stuff on its own, and Fortnite must have god knows how much additional crap in there, so if this is (or will be) their replacement for Perforce internally, then it'll be getting a good deal of testing. (If they're just chucking it over the wall, though... well, sheesh, you first...)
(Perforce is the standard thing for games, and pretty well it works too, and hopefully this will deliver it a well-needed kick. It was sold to private equity about 10 years ago, and it feels like they've been coasting ever since. (Perhaps users in other sectors are happier though?))
by tom_ - I reluctantly agree. I was interested to read the system design doc[1] but it's so many pages long and so full of redundant statements and needless details[2] that I gave up a couple sections in. The numerous "it's not X, it's Y" constructions give the game away. If they can't be bothered to read these docs themselves, why should I?
Anyway it's probably fine software and I am genuinely going to give it a shot for a usecase I have involving large image files. But the LLM-generated docs don't inspire confidence.
[1] https://epicgames.github.io/lore/explanation/system-design/
[2] They literally have a section header "10.1 Revision state as a 320-byte fragment". The byte size isn't even relevant in the code as an implementation detail, much less belongs in a design doc. No one read this doc before publishing it.
by coldpie - There was and still is a very nice competitor in this space called PlasticSCM. They were bought by Unity a few years ago. Unity has not been a good steward. They should have done what Epic is doing and open sourced it. But instead they chose to give it P&L responsibility. Curious what it's contributing to their financials.by bentt
- Plastic is usable on surface, but doesn't scale well. If you've ever looked at what Plastic does when you use its git fast-export compatible feature, the results for merge commits are horrible to behold, e.g. delete of a directory followed by add of a file into same dir, then delete of it then rename.by robaato
- Seeing PlasticSCM wither like this is sad. I had rather high hopes for this system to successfully compete with Perforce, but history worked out differently.by gmueckl
- The idea sounds good, even if Epic's recent track record of tools is not inspiring. But the commit messages etc. are very clearly products of vibe-coding. And version control is not the situation where "works 97% of the time" is a good-enough bar.
Passing for now.
by pkasting - About the recent track record, is there some technical problem or just drama with Unreal Engine that I'm not aware of? (I already have the same opinion about using AI-coded VCS.)by frollogaston
- >fully open source >look inside >Lore Desktop Client is available as binaries only, download the installer for your platform here:
- There’s a “Repositories” link at the top of the page that links to https://lore.org/#repositories, WhyHow links to various GitHub repos, including https://github.com/EpicGames/lore, which claims to have code for the CLI. I see no reason to suspect that claim is incorrect. The code likely lives in https://github.com/EpicGames/lore/tree/main/lore-client)by Someone
- to be fair, that's just the desktop client. You can use or build on top of the CLI
they do say they will open source it, but who knows:
"It isn’t open source yet—it currently depends on some proprietary components, including Epic’s internal design system—but we’re committed to open-sourcing it in the future"
by lentil_soup - https://epicgames.github.io/lore/roadmap/#desktop-client
> Open-source the desktop client so the community can build on its full graphical experience, not just download it. An early desktop client already exists as a binary download, but it isn't open source yet — it depends on some proprietary components, including Epic's internal design system. We're working to make all of it available in the open so that the client can ship as source alongside the rest of Lore. Lore is an open project, so it is important that the desktop client — which will be one of the main ways many people will interact with Lore — is also fully open so that the community is free to review, extend, and shape it.
by O5vYtytb - "Full-surface API" is a feature nobody here has mentioned. Is that a dig at how git intentionally has no linkable library? I saw this earlier https://news.ycombinator.com/item?id=48470604by frollogaston
- I don't know if it's a jab at git. Git does have `porcelain` to accommodate programmatic interaction. It's not linkable, but it's still an API.by ibejoeb
- The premise is that Git-LFS sucks, so we need to build a new data versioning system (in Rust, from scratch). While I mostly agree with this premise, but there are already lots of existing (mature) data versioning systems with the same tricks under the hood:
- Pachyderm (Go): https://github.com/pachyderm/pachyderm
- XetHub (acquired by HuggingFace): https://huggingface.co/blog/xethub-joins-hf
- LakeFS (Go): https://github.com/treeverse/lakeFS
- Oxen (Rust): https://github.com/Oxen-AI/Oxen
I guess with AI, anyone can vibe code a content-addressed, chunk-level deduped, versioning system in Rust these days...
But jokes aside, Lore seems really cool! What's interesting is the realization that different domains/industries have similar problems, but they don't seem to be cross-polinating. In this case AI and Gaming both need a storage system that can version control large binary files at scale. I think there's lots of opportunities to share ideas here, but perhaps the lack of idea sharing (currently) creates opportunity!
- I don't think the needs are exactly the same. I believe in AI the big binary files are normally written once, while in gamedev, they are constantly updated.
That already warrants different storage architectures.
by LtdJorge - There's also git-annex and iterative DVC. I used xethub a fair bit (was the earliest user, in fact) and I thought it was better than git annex, git-lfs and DVC, but still did start to struggle past a certain size. I think part of the problem was just git itself, and the compromises required to have a hybrid repo. So I'm happy to see this vcs doesn't use it. xethub did start shipping a version of their product that did not use git but I didn't get the chance to try it. I've also tried oxen and it wasn't bad at first, but soon ran into some weird issues with the repo state which I didn't really try to debug. It is clear to me at this point, given my experience with all these systems -- none of which I've been 100% happy with -- that "git for data" is a nontrivial problem.by dimatura
- I'd trust this project more if it was named Data.by jacobgold
- "Lore" is appropriate. Epic games is a very unethical company that steals from people. Myself in paticular. I bought Rocket League the game for linux from Psyonix. Epic bought Psyonix and immediately removed the game clients for linux and mac os. I can no longer play. They stole from me and many others. It'd be one thing if they just shut down the game entirely, but stealing it from only some people while keeping it going for others is worse than just killing games.by superkuh
- All Data is Lore. I mean lore is a superset of data. I mean data is lore with a special attribute.
I'm not just picking nits here. And this is not cynicism.
so there you go.
by analog8374 - Oh brother.
Don't be too hard on Lore.
- If it were Data instead of Lore, it would reject any commit messages that used contractions such as "I'm" and "can't" ;-)by manifoldgeo
- Dunno, this seems fully functional?by zdw
- Yeah, I'm still concerned about crystalline entities suddenly showing up. Have they ever fixed it? I don't see anything in the issue tracker, probably because no one was left last time to report it...by HansHamster
- Turns out it is not really new but only open sourced it now. From the FQA.
>Lore, formerly called Unreal Revision Control, is the built-in version control system for UEFN (Unreal Editor for Fortnite), where creators have been using it to version their islands. It is also seeing progressive adoption by internal Epic teams, and is being implemented as the backing store for UEFN’s cook pipeline, where it replaces traditional intermediary storage layers—eliminating redundant file transfers and significantly reducing the time between publishing changes and those changes being playable.
Surprised it is in Rust and not Epic C++ or Verse. I wonder why.
by ksec - Honestly it inspires rather more confidence in me to see a tool that has actually been used for a while and is just now being released for public use as well. Unless, of course, it's being released because they've decided to stop development, but I don't think that's the case here.by yjftsjthsd-h
- It's a separate tool from Unreal Engine, so you don't need to constrain yourself to its conventions. You're also not going to use UObjects, its reflection layer, serialization, and all that other stuff for a tool that's strictly for version control. Plus you're going to tie yourself to all the issues and slowness of the engine. Epic made this mistake with the Epic Games Launcher, which is essentially an instance of the engine running, and a huge source of various issues.
As for Verse vs Rust, Verse is used in UEFN experiences, but it is _far_ from any kind of production state. It's also intrinsically tied to UEFN. It's not like you can download a standalone compiler or REPL for Verse.
by LugosFergus - I suspect the use of Rust rather than C++ might have something to do with the fact that Simon Peyton Jones and Lennart Augustsson (both of Haskell fame) both work at Epic and there would have been a strong internal push to do this in a language with some functional programming features. Rust rather than Verse because that would probably not be the right tool for the job (even if Simon works on it). Rust rather than Haskell probably because of performance -- DARCS never caught on partly for performance reasons.by wrwills
- We had to use Perforce (Helix Core Cloud) at my last game studio, and it is the de facto industry standard that most of your creative staff is already familiar with. The programmers don't love it, but they don't rule the roost in games. It's also the safe, verified default for working with Unreal Engine 5.
It does show its years though. We were one of the first users of the Perforce cloud offering, as we were small and didn't want to self-host ourselves, but it was a bit of a rickety experience. You had to register an Azure account in order to be able to access the service, and you had to ask support to modify things like triggers. Coming from the world of GitHub and other SaaS products, you could tell it was an attempt to retrofit an older model into a new skin.
The Git LFS path has some unofficial support as well, but you are on your own when things go poorly. Epic doesn't provide much help there.
Competition in this space is welcome, especially if they're planning to make it fully officially supported by the Engine.
I wrote about why merging files isn't as common in the world of game dev for folks coming from the world of text: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
by akurilin