Forgot your password?
Close
typodupeerror
Open Source Games

Epic Games Announces Lore Open-Source Version Control System (phoronix.com) 35

Posted by BeauHD from the new-and-improved dept.
Epic Games has released Lore, an MIT-licensed version control system written in Rust and designed specifically for "games and entertainment purposes with large file sizes," reports Phoronix. From the report: While there is Git LFS for large file storage with Git, Epic Games has crated Lore as a version control system designed entirely around the large file needs of modern game development as well as multimedia/entertainment purposes. Lore is designed to be fast and efficient for large files including binary files, and be easy-to-use including for 3D artists and more.

The Lore documentation elaborates more on its differences and motivation for development compared to Git: "No existing system was designed for the combination of constraints that large game and entertainment projects require: arbitrary content types, multi-axis scale, multi-tenant safety, and a fully open specification and license. [...] Lore is designed to combine what works in each (Git's content-addressed revision graph and centralized systems): a centralized server-of-record for durability, access control, and conflict resolution; content-addressed storage with fragment-level deduplication that is as effective on a multi-gigabyte binary as on a kilobyte of text; sparse, lazy working copies that materialize only what you need; free branching; and a fully open, publicly versioned specification and MIT license. Normal editing operations -- staging, committing, branching, diffing -- never require a network round trip." You can learn more at Lore.org. All the code is available on GitHub.
This discussion has been archived. No new comments can be posted.

Epic Games Announces Lore Open-Source Version Control System More

Epic Games Announces Lore Open-Source Version Control System

Comments Filter:

  • Storing 'Data' (Score:5, Funny)

    by bill_mcgonigle ( 4333 ) * on Wednesday June 17, 2026 @01:06PM (#66197196) Homepage Journal

    It's all well and good until Lore steals Data's emotion chip.

  • [Yawn] (Score:2)

    by PPH ( 736903 )

    Aircraft manufacturing data. Done. Decades ago.

    The weight of the documentation must be greater than the weight of the airplane before it is permitted to fly.

    • Re: (Score:2)

      by bn-7bc ( 909819 )
      nah it*s all digital today, it all fits on an emmc and those don't weigh much lol. Also iu suspect you overestimaye the weight of paper at least for larger aircraft (think 747 and the like where the paint job alone mey weigh in at several hundred kilos , if not signifivantly more) you can squeeze a lot of text and drawings on 100Kg of paper

  • This could actually be great! (Score:5, Interesting)

    by Oh really now ( 5490472 ) on Wednesday June 17, 2026 @01:23PM (#66197212)
    I haven't dug too deeply in the details, but possibly might help in my environment. Maybe. Depends on the people. My art department has a huge file storage problem because they angrily insist on storing all of their collaborative work on a single SMB share. Worse, they choose to work directly on the NAS because that's how they linked all the assets within their documents. Invariably, they clobber each others work, and Adobe products randomly blow up files. I periodically snapshot the volume but that's more of a bandaid than a solution. The only problem moving them to a version control system is I'm not quite sure they'd understand enough to use it. They struggle a LOT with the concept of file locations, file times, etc. and literally believe "the system" stores each change they make as they make it. Worse they huff when they find out we can't go back through each change for them. One dude literally said "the system" only stored some of his edits despite there clearly only being one new file revision on disk.

    • Huh. Now you've got me wondering whether the members of our department's PR team are holding down second jobs in your art department.

      • I think it's probably endemic to every art/PR/marketing department. And they never listen!

        • Linux switched to Git in 2006.

          A replacement is needed, even if it is a wrapper on top of git. (Yes Lore is not git)

          The dozens of non-programmer people we've had to train on using Git and the fundamental disconnect of terminology git uses is a negative.

    • Oh no. They're trying to work of the NAS in Adobe software? I had that problem when I worked at a company that had a marketing department. Adobe is pretty clear about that being a really bad idea that they will not help with, and I had a hell of a time getting the art people to stop.

      You're in a tough spot. I don't think there's a real solution past telling them, "I told you it wouldn't work, there's nothing I can do. Next time, drag it to your computer before you open it in Photoshop (or whatever)."

      • I'm surprised there hasn't been more development to get desktop applications, such as Adobe's, pushed to a client/server model. That would facilitate collaborative work in real-time. They could take all of the functions of each application, put them behind REST endpoints, and broadcast the results to all clients that currently have that "file" open. And since the "file" is just a series of REST calls, you could log them and their parameters and effectively have infinite undo history.

        In Adobe's case th
        • Adobe software eats hard drives like candy. Very heavy on temp files. An image being worked on could be a hundred times larger than the final file will be (at the same resolution), without factoring in the scratch space. It works on the cloud because they can provide a fast enough UI, but a client-server model could go very wrong. I don't even want to begin thinking about how wrong concurrent edits could get.

          Unless they've changed things.

    • Re: (Score:3)

      by Himmy32 ( 650060 )
      There's already a bevy of "Digital Asset Management" suites directed at big shops that already handle this problem that will be more ergonomic for artists. At the medium scale, SAN level dedupe with snapshotted backups and then letting the department go wild on separately saving small changes is practical.

      The idea of trying to herd "creative" cats into using an obscure version control.

    • The key is you need your assets to be NOT smb mapped, and then give them a drag and drop VCS client.

    • Re: (Score:2)

      by DrXym ( 126579 )
      Dealing with large repos and large binary blobs is definitely the biggest issue with Git. So many solutions have been proposed over the years and none of them seems to be ideal. e.g. putting blobs in lfs is better than storing them in the repo, but it means you need something like gitlab or nexus to store the blobs and they're not necessarily backed up with the rest of the repo.

      I think the most viable thing these days is probably Scalar, which is the successor to VFS for Git and has been integrated into g

    • I actually built a basic versioning system using Photoshop scripting for our animation studio's 2D department like a decade ago because we had a lot of 2D artists for a new project after a couple of years of me being the only 2D artist in the studio.
      We already had pretty beefy and fast storage servers because the render farm needed to have access to all the 3D data anyway.
      So I basically wrote a UI panel in Photoshop that allowed you to navigate to a specific asset in the show's hierarchy and commit a versio

  • Perforce (Score:5, Interesting)

    by ajedgar ( 67399 ) on Wednesday June 17, 2026 @01:30PM (#66197218)

    Perforce does all of that (and provides Git compatibility) but is not open source. In fact Epic games uses Perforce extensively, so this is there way of getting out from under the licensing fees.

    https://www.perforce.com/

    • BitKeeper also did everything Git could back in the day.

      • > BitKeeper also did everything Git could back in the day.

        BitKeeper could do things Git couldn't even dream about (because Git didn't exist).

        Every masterpiece (BitKeeper) has its cheap copy (Git). :) :)

    • I hate hate hate perforce. Managing it was the lowest point in my DevOps/IT/SD journey.

      • I run my own Perforce server infrastructure on a secondhand rack server for handling 3D art, because even though it's a massive pain in the ass, it's still preferable to trying to use Git for the same purpose.

  • bitter (Score:2)

    by nyet ( 19118 )

    Somebody is mad that the git maintainers think their ideas are dumb.

    BTW where did bitkeeper go, Epic?

  • A lot of game teams had been using Perforce, which sucks.

    • Perforce and Alienbrain come the closest to cleanly mapping onto the workflow needs of the art team in game studios. In some places the coders from dev side were forcing Git onto the art team and I can speak from extremely infuriating personal experience that Git, in that context, is a disaster and an active hindrance. It's made for code. It gets in the way of handling art content in that environment.

      I trust Epic has run into that themselves and designed Lore to go around those problems.

  • Is projfs going to be like the old ClearCase version-controlled filesystem from back in the old days?

    That would be completely awesome.

  • I'm maxed out on my free Perforce license and I will never, EVER use Git for art content again even if you put a gun to my head.

    I've been hoping somebody would tackle this need as a FOSS project for a long time. Thank you, Epic!

    Now I gotta figure out how to migrate multiple Perforce depots to this.

  • git annex (Score:1)

    by GM ( 7955 )

    Instead of git LFS, "git annex" provides everything needed apparently (and more). Especially on the offline, deduplication, lazy and multi-tenant part.
    Not sure what "fragment-level" deduplication means, but as rsync is also supported as transport in git annex, the point should be covered too.

Slashdot Top Deals

So you think that money is the root of all evil. Have you ever asked what is the root of money? -- Ayn Rand

Close