Today I'm sharing lore-swift, Swift bindings for Lore, Epic Games' new version control system: mattt/lore-swift
A few months ago, I started making a videogame with my kids. Until then, I'd led a semi-charmed existence of not having to think about Git LFS. But this asset-heavy project brought me back to the dark days of smudge filters and (apparently, given the price) gold-plated blob hosting. So after reading about Lore on HN, I decided to take a look.
I ran a simple trial on my Mac with the game's art, music, and sound effects so far: about 1,300 files and 395 MB, in Lore and in Git with LFS, side by side. After the import, Lore's local store took 4.8 MiB, against 375 MiB for .git (mostly the LFS cache). Five small edits to a 32 MB WAV file grew the Lore server by 1.9 MiB, and the LFS server by 155 MiB.
Provenance matters for this project, which mixes handmade and generated assets. Lore has built-in primitives for it, which is nice. Files, revisions, and branches can carry typed metadata that's part of immutable history, and files can declare tagged dependencies on each other. A generated sprite can point back to the drawing it came from, and the drawing knows what was made from it.
Lore isn't quite ready for my project yet. In the version I tried, locks didn't do much with auth off, and staging needed the server unless you cloned with a cache. I've also reported a couple of bugs so far (EpicGames/lore#263 & #264). But overall it's promising.
For the way we work, I wanted a native macOS app more than a command line, so I started with the foundation. lore-swift covers nearly all of Lore's C API with async/await, including progress streams for clone, push, sync, and interactive login.
These bindings are a start. I'll have more to share as I build on them!
38 likes · 1 repost · 2,170 views
Mentions
Today I'm sharing lore-swift, Swift bindings for Lore, Epic Games' new version control system: mattt/lore-swift A few months ago, I started making a videogame with my kids. Until then, I'd led a semi-charmed existence of not having to think about Git LFS. But this asset-heavy project brought me back to the dark days of smudge filters and (apparently, given the price) gold-plated blob hosting. So after reading about Lore on HN, I decided to take a look. I ran a simple trial on my Mac with the game's art, music, and sound effects so far: about 1,300 files and 395 MB, in Lore and in Git with LFS, side by side. After the import, Lore's local store took 4.8 MiB, against 375 MiB for .git (mostly the LFS cache). Five small edits to a 32 MB WAV file grew the Lore server by 1.9 MiB, and the LFS server by 155 MiB. Provenance matters for this project, which mixes handmade and generated assets. Lore has built-in primitives for it, which is nice. Files, revisions, and branches can carry typed metadata that's part of immutable history, and files can declare tagged dependencies on each other. A generated sprite can point back to the drawing it came from, and the drawing knows what was made from it. Lore isn't quite ready for my project yet. In the version I tried, locks didn't do much with auth off, and staging needed the server unless you cloned with a cache. I've also reported a couple of bugs so far (EpicGames/lore#263 & #264). But overall it's promising. For the way we work, I wanted a native macOS app more than a command line, so I started with the foundation. lore-swift covers nearly all of Lore's C API with async/await, including progress streams for clone, push, sync, and interactive login. These bindings are a start. I'll have more to share as I build on them!