- Lore yang dikelola Epic Games adalah sistem kontrol versi open source generasi berikutnya yang ditujukan untuk proyek yang menangani kode dan aset biner besar secara bersamaan
- Dapat dimulai dengan cepat secara lokal lalu diskalakan sesuai kebutuhan, serta mendukung repositori dan tim berskala besar melalui data bersama yang dapat digunakan ulang dan pengunduhan saat dibutuhkan
- Menggunakan repositori terpusat berbasis content-addressed, serta merepresentasikan status repositori dan riwayat perubahan dengan Merkle tree dan revision chain yang immutable
- File besar disimpan sebagai chunk yang dapat digunakan ulang, dan dengan sparse workspace serta on-demand hydration, semua data tidak perlu diunduh sejak awal
- Dirilis di bawah lisensi MIT dan menyediakan CLI, API C/C++, C#, Rust, Go, Python, JavaScript, serta berbagai repositori SDK
Manajemen versi untuk kode dan aset besar secara bersamaan
- Lore adalah sistem kontrol versi open source generasi berikutnya yang dikelola Epic Games
- Dirancang dengan target skalabilitas tinggi pada skala data, skala tim, distribusi tim, dan ukuran repositori
- Dioptimalkan untuk proyek yang menggunakan kode dan aset biner besar secara bersamaan
- Proyek di industri game dan hiburan disebut sebagai contoh
- Menangani kebutuhan kolaborasi antara developer dan artist sekaligus
- Dapat dimulai dalam hitungan menit dalam mode lokal, lalu diperluas sesuai kebutuhan
- Menyediakan fondasi agar tim dapat membangun alur kerja kolaborasi yang cepat, intuitif, dan praktis
Struktur untuk skalabilitas dan penanganan file besar
-
Data bersama dan API
- Fitur utama disusun dengan fokus pada skalabilitas dan penanganan aset besar
- Bertujuan untuk melakukan penskalaan tanpa penurunan kecepatan melalui data bersama yang dapat digunakan ulang dan pengunduhan saat dibutuhkan
- Dapat membuat, mengelola, dan menyinkronkan branch dengan cepat
- Seluruh fitur Lore dapat diakses satu banding satu melalui CLI
- Mendukung perluasan, kustomisasi, dan integrasi melalui API untuk C/C++, C#, Rust, Go, Python, dan JavaScript
-
Repositori berbasis content-addressed
- Struktur repositorinya adalah sistem kontrol versi content-addressed yang terpusat
- Data repositori disimpan dan direferensikan dengan hash konten serta direpresentasikan dengan Merkle tree
- Mendukung perbandingan cepat, pemeriksaan integritas, serta penggunaan ulang data antar riwayat dan branch
- Tanda tangan hash revision diturunkan dari status revision yang mencakup hash revision induk dan hash data yang disertakan
- Struktur ini membentuk rantai immutable dengan integritas kriptografis
-
Penyimpanan chunk dan pengunduhan saat dibutuhkan
- Penanganan file besar dan workspace menggunakan penyimpanan chunk dan on-demand hydration
- File disimpan sebagai chunk yang dapat digunakan ulang dan menggunakan pencarian berbasis indeks
- Mengurangi duplikasi serta mengefisienkan pembaruan dan transfer aset biner besar
- Workspace dapat tetap ringan dengan hanya mengambil data file yang diperlukan
- Dengan sparse workspace, semua data tidak perlu diunduh sejak awal
-
Model server dan branch
- Struktur server adalah arsitektur berbasis layanan yang mencakup caching
- Caching di depan durable storage mendukung penskalaan throughput untuk tim besar dan repositori besar
- Branch berfungsi sebagai mutable reference yang ringan sehingga biaya pembuatan dan perpindahannya rendah, tanpa duplikasi data dasar
Repositori publik dan dokumentasi
- Epic Games merilis Lore sepenuhnya sebagai open source di bawah lisensi MIT
- Lore Library, Server & CLI
- Javascript SDK
- Python SDK
- C# SDK
- Go SDK
- Dokumentasi dan dokumen desain sistem tersedia di Lore docs dan system design doc
2 komentar
Komentar Hacker News
Untuk memberi konteks bagi pembaca HN yang belum pernah membuat game, ini bukan alat yang mencoba bersaing dengan Git untuk pengembangan perangkat lunak umum, melainkan alat yang mencoba bersaing dengan Perforce untuk pengembangan game
Git cukup baik untuk file berbasis teks seperti kode, tetapi sangat lemah untuk kolaborasi pada file non-teks seperti tekstur, model 3D, dan file audio. Misalnya, tidak ada cara yang masuk akal untuk menggabungkan hasil edit asinkron dari dua artis, jadi mungkin perlu menerapkan penguncian eksklusif pada aset yang sedang diedit oleh satu artis
Pemimpin de facto di area ini adalah sistem proprietari Perforce(https://www.perforce.com/products/helix-core). Menurut teman-teman pengembang game, Perforce sangat bagus saat berjalan lancar, tetapi juga punya cukup banyak hambatan sampai-sampai perlu dikelola oleh tool engineer dan sesekali diperbaiki secara manual. Git LFS juga merupakan alternatif, tetapi untuk proyek tim dengan lebih dari 3–4 orang, semua orang tampaknya lebih memilih Perforce
Di P4, akses ke direktori tertentu bisa dibatasi hanya untuk orang yang sudah menandatangani NDA yang diperlukan, tetapi di Git pendekatannya serba semua boleh atau semua ditolak. Mungkin bisa dirakit dengan submodule, tetapi jika tidak dirancang begitu sejak awal, struktur repositori harus dirombak besar-besaran
git clone, yaitup4 sync, bisa berukuran terabyteGit lemah dalam menangani aset biner, tekstur, model, suara, dan semacamnya pada skala seperti ini
Jika ada aset yang sering diperbarui pada tahap awal pengembangan, biaya penyimpanan itu harus ditanggung sepanjang umur repositori. Dalam pengembangan game, ini sering terjadi. Sebagian besar aset bolak-balik berkali-kali di awal, lalu setelah selesai tidak pernah disentuh lagi
Hari ini saat mendorong perubahan ke Github, saya kembali berpikir betapa tidak ramah penggunanya UI Git
Output seperti
Enumerating objects,Counting objects,Delta compression,Writing objects,pack-reused,Resolving deltasmungkin menyampaikan sesuatu bagi pengguna Git garis keras, tetapi bagi kebanyakan orang itu benar-benar omong kosong. Apa sebenarnya “delta compression”, kenapa saya perlu tahu berapa thread yang dipakai, dan sulit memahami arti “objects”, objek “local”, atau “pack-reused”Dari dokumentasinya, Lore tampaknya menangani bagian ini sedikit lebih baik. Tampilannya seperti
Pushing 1 fragment(s),Pushed 1 fragment(s), 124.00 bytes,Pushed revision 1 -> a3f8c2d1... to branch main-v. Mungkin hanya karena tidak ada yang pernah menyentuhnya, dan selama puluhan tahun orang belajar untuk mengabaikannyaObjek dirujuk oleh tree, dan tree pada dasarnya adalah direktori. Tree lalu dirujuk oleh commit atau tag untuk membentuk DAG, dan pointer bernama yang menunjuk ke berbagai titik di sana adalah branch dan referensi tag: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Menyimpan banyak loose object sangat tidak efisien, jadi Git secara berkala mengemas objek-objek itu ke dalam pack. Untuk menghemat ruang, objek di dalam pack dibandingkan satu sama lain lalu dikompresi, dan inilah delta compression: https://git-scm.com/docs/git-pack-objects, https://github.com/git/git/blob/master/Documentation/technic...
Saat push atau pull, protokol transfer Git menghitung objek apa saja yang dimiliki kedua pihak lalu hanya mengirimkan perbedaannya. Selain itu, objek yang belum dikemas juga didelta-compress di kedua sisi untuk menghemat ruang: https://github.com/git/git/blob/master/Documentation/technic...
Git adalah proyek open source buatan para geek, jadi ia menampilkan semua informasi ini. Abaikan saja. Jika benar-benar ingin tahu, semuanya terdokumentasi di buku Git dan direktori dokumentasi yang ditautkan di atas
Sekarang saya makin bisa memahaminya. Dari sudut pandang UI, ini peningkatan besar dibanding Git. Hanya saja, alur kerja branch-nya butuh waktu untuk dibiasakan
Saya sangat merekomendasikan untuk langsung melihat isi direktori
.git. Setelah itu, kebutuhan dukungan Git untuk pegawai baru praktis turun mendekati nolPengumuman ini tampak sangat menjanjikan khususnya untuk pengembangan game Unreal. Untuk penggunaan lain, saya tidak terlalu tertarik.
Perforce jelas butuh pesaing. Alasan Perforce menjadi pemain kuat yang mapan bukan karena ia luar biasa sederhana untuk dipakai atau dikelola. Misalnya kalau hanya melihat pekerjaan branch, Git sebenarnya jauh lebih sederhana.
Alasan P4 sering disukai dalam pengembangan game adalah dukungan proyek besar, perizinan, penguncian file, dan hal-hal lain yang juga sudah disebut di komentar lain. Alasan penting lainnya adalah P4 didukung dengan sangat baik di dalam Unreal Engine. Memang tidak sempurna, tetapi karena ini alat yang dipakai Epic secara internal, ini adalah sistem kontrol versi yang paling didukung dengan baik. Plugin Git tidak dipakai Epic secara internal, jadi rasanya menyakitkan karena masih belum matang.
Karena itu, saya berharap Lore akan mendapat dukungan tingkat satu. Kalau dukungan Unreal lebih baik, saya pasti akan jauh lebih sering merekomendasikan Git. Sebagai konteks, saya sudah hampir 20 tahun bekerja di pengembangan game, di perusahaan berukuran dari 2 orang sampai 200 orang, dengan berbagai engine dan sistem kontrol versi. Saya lebih memilih Git di tempat yang memungkinkan, tetapi untuk Unreal, itu biasanya hanya untuk proyek kecil atau saat anggota tim sangat paham teknologi. Pilih saja alat yang cocok untuk pekerjaan dan timnya.
https://github.com/EpicGames/UnrealEngine/pull/14630
Di studio game saya sebelumnya, kami harus memakai Perforce, tepatnya Helix Core Cloud, yang merupakan standar industri de facto yang sudah akrab bagi sebagian besar peran kreatif. Para programmer memang tidak menyukainya, tetapi pihak yang memegang kendali di industri game bukan programmer. Ini juga adalah default yang aman dan sudah teruji untuk dipakai bersama Unreal Engine 5.
Meski begitu, kesan tuanya tetap terasa. Kami kecil dan tidak ingin self-hosting, jadi kami termasuk yang lebih awal memakai layanan cloud Perforce, dan pengalamannya cukup tersendat. Untuk mengakses layanannya, kami harus mendaftarkan akun Azure, dan untuk mengubah hal-hal seperti trigger, kami harus meminta ke tim dukungan. Kalau datang dari dunia GitHub atau produk SaaS lain, terasa seperti upaya membungkus model lama dengan kulit baru.
Jalur Git LFS juga ada sedikit dukungan tidak resmi, tetapi kalau semuanya berantakan, Anda harus membereskannya sendiri. Epic tidak banyak membantu di sana. Apalagi jika targetnya dukungan resmi yang penuh di engine, persaingan di area ini sangat layak disambut.
Saya menulis tentang kenapa penggabungan file tidak umum di dunia pengembangan game, untuk orang-orang yang datang dari pengembangan berbasis teks: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
Saya baru saja mengambil alih tim yang memakai Git. Saya tahu Git adalah sistem kontrol versi yang disukai semua orang, tetapi untuk game ini nyaris jadi salah satu pilihan terburuk. Dengan Git, waktu review art harus diukur dalam hitungan jam, sedangkan dengan Perforce jadi hitungan detik. Ini bukan bercanda.
Alat-alat menarik yang dipakai UE5, misalnya Horde atau UBA, membutuhkan Perforce.
Tetapi Perforce memegang posisi industrinya dan tidak melakukan apa-apa. Harganya sangat mahal, dan biaya operasional hosting juga tidak kecil. Anda harus meng-host-nya sendiri, dan dari sisi performa memang lebih baik dilakukan sendiri, tetapi setelah instalasi awal, perawatannya benar-benar menyakitkan. Ada tanda-tanda mereka mencoba sesuatu, tetapi tidak ada arah yang jelas, dan hampir semua yang mereka lakukan bertentangan dengan akal sehat atau basis penggunanya. Produk intinya terus hanya ganti nama tanpa perbaikan nyata.
Ini pelajaran tentang bagaimana perangkat lunak proprietari bisa menjadi penjara. Saya ingin memakai alat code review yang lebih baik daripada Swarm, ingin mengintegrasikan SSO tanpa hook LUA aneh yang bikin segfault di mesin saya, dan ingin menjalankan backend penyimpanan terdistribusi alih-alih bergantung pada SSD raksasa dan backup journal. Bahkan lisensinya diikat ke alamat IP server utama sehingga pemulihan backup pun tidak bisa dilakukan.
Ini teknologi yang terlupakan, dan pihak yang menjalankan perusahaan itu terasa seperti zombie.
Saya tidak tahu apakah masalah perizinan sudah dibereskan, atau apakah model kontrol versi terdistribusi/terpusat campuran seperti ini—di mana checkout per file berinteraksi dengan alur kerja berbasis branch tradisional—sudah benar-benar tertata.
Jika melihat FAQ, ternyata ini bukan produk yang sepenuhnya baru, melainkan baru sekarang dirilis sebagai open source.
Ada penjelasan seperti ini: “Lore, yang sebelumnya disebut Unreal Revision Control, adalah sistem kontrol versi yang tertanam di UEFN (Unreal Editor for Fortnite), dan telah digunakan para kreator untuk mengelola versi pulau mereka. Tim internal Epic juga mulai mengadopsinya secara bertahap, dan sistem ini sedang diimplementasikan sebagai backend repository untuk pipeline cook UEFN, menggantikan lapisan penyimpanan perantara yang ada untuk menghilangkan transfer file duplikat dan secara signifikan mengurangi waktu dari setelah perubahan dipublikasikan hingga bisa dimainkan.”
Cukup mengejutkan karena ini memakai Rust, bukan Epic C++ atau Verse. Penasaran apa alasannya.
Alasan bukan Verse kemungkinan besar karena pekerjaan ini memang tidak cocok untuk Verse. Walaupun Simon mengerjakan Verse, itu tetap masuk akal. Alasan bukan Haskell mungkin karena performa. DARCS juga punya sisi yang membuatnya tidak banyak diadopsi karena masalah performa.
Selain itu, itu justru akan mengikatnya pada berbagai masalah dan kelambatan engine. Epic pernah membuat kesalahan ini di Epic Games Launcher. Pada dasarnya itu berjalan seperti menjalankan instance engine, dan menjadi sumber besar dari berbagai masalah.
Jika membandingkan Verse dan Rust, Verse dipakai di dalam pengalaman UEFN, tetapi masih jauh dari status production-ready. Selain itu, Verse pada dasarnya terikat ke UEFN. Kita juga tidak bisa sekadar mengunduh compiler mandiri atau REPL-nya.
Tentu pengecualiannya kalau ini dibuka karena pengembangannya mau dihentikan, tetapi dari sini tampaknya bukan kasus seperti itu.
Full-surface API adalah fitur yang belum disebut siapa pun di sini. Saya penasaran apakah ini sindiran ke Git, yang memang sengaja tidak menyediakan library yang bisa di-link. Saya pernah melihat tulisan ini: https://news.ycombinator.com/item?id=48470604
porcelainuntuk berinteraksi dengan program. Memang bukan dalam bentuk yang bisa di-link, tetapi tetap saja itu sebuah API.Premisnya adalah bahwa Git-LFS kurang bagus, sehingga perlu membuat sistem kontrol versi data baru dari nol dengan Rust. Saya pada umumnya setuju dengan premis ini, tetapi sebenarnya sudah ada cukup banyak sistem kontrol versi data matang yang memakai trik serupa secara internal.
Pachyderm(Go): https://github.com/pachyderm/pachyderm
XetHub(HuggingFace mengakuisisi): https://huggingface.co/blog/xethub-joins-hf
LakeFS(Go): https://github.com/treeverse/lakeFS
Oxen(Rust): https://github.com/Oxen-AI/Oxen
Mungkin sekarang, berkat AI, siapa pun sudah bisa melakukan vibe coding untuk sistem kontrol versi dengan content addressing, deduplikasi per chunk, dan sebagainya memakai Rust.
Di luar bercandanya, Lore terlihat sangat keren. Yang menarik adalah bahwa domain dan industri yang berbeda tampaknya memiliki masalah serupa, tetapi tidak banyak pertukaran ide yang terjadi. Dalam kasus ini, baik AI maupun game sama-sama membutuhkan sistem repositori untuk version control file biner berukuran besar. Tampaknya ada banyak peluang untuk berbagi ide, dan kurangnya pertukaran saat ini sendiri bisa menjadi peluang.
Perbedaan ini saja bisa menuntut arsitektur repository yang berbeda.
Sebagian masalahnya, menurut saya, adalah kompromi yang diperlukan untuk mempertahankan Git itu sendiri dan repository hibrida. Karena itu saya senang sistem kontrol versi ini tidak memakai Git. xethub juga mulai mengeluarkan versi produknya yang tidak memakai Git, tetapi saya belum sempat mencobanya.
Saya juga pernah memakai oxen, dan awalnya tidak buruk, tetapi tak lama kemudian saya menemui masalah aneh terkait status repository dan tidak men-debug-nya terlalu dalam. Setelah mencoba semua sistem ini, jelas tidak ada satu pun yang terasa 100% memuaskan, dan Git untuk data memang bukan masalah sepele.
Saya penasaran perusahaan mana yang benar-benar akan menerapkan sistem ini, misalnya dalam 2 tahun ke depan.
Helix dan Perforce sudah mengerjakan hal ini selama puluhan tahun, dan karena ini bagian dari bisnis inti mereka, keduanya bisa dipercaya. Kita tahu mereka kemungkinan akan terus memelihara produknya untuk waktu yang lama.
Tetapi kalau Epic meninggalkan proyek ini besok, bisnis mereka tidak akan terpengaruh sama sekali. Bahkan bisa jadi itu membantu bisnis karena mereka mendapatkan kembali sumber daya pengembangan.
Ini mirip dengan pertanyaan mengapa orang harus percaya bahwa Cloudflare akan terus berinvestasi pada EmDash dalam jangka panjang. Cloudflare tidak punya minat pada CMS. Memberikan pengalaman terbaik bagi pembaca, penulis, dan pemilik situs bukanlah bisnis mereka. Ini nyaris seperti proyek sampingan yang hampir tidak terkait dengan bisnis utama mereka.
Di area ini, sejak dulu sampai sekarang sebenarnya sudah ada pesaing yang cukup bagus bernama PlasticSCM. Beberapa tahun lalu Unity mengakuisisinya, tetapi Unity bukan pengelola yang baik.
Seharusnya mereka merilisnya sebagai open source seperti yang dilakukan Epic, tetapi mereka malah memilih menjadikannya unit dengan tanggung jawab laba-rugi. Saya penasaran seberapa besar kontribusinya terhadap keuangan Unity.
Komentar Lobste.rs
Karena dioptimalkan untuk proyek game/entertainment yang menangani kode dan aset biner besar sekaligus, akhirnya ada juga yang muak dengan dominasi Perforce selama puluhan tahun lalu membuat sesuatu
Waktu pertama lihat sepertinya belum ada, tapi penasaran kenapa sekarang diberi tag vibecoding
Misalnya, penjelasan seperti “Mercurial dan Sapling berfokus pada riwayat teks sedangkan Lore mengutamakan biner” itu keliru. Mercurial juga merupakan struktur yang dibangun di atas model objek biner dengan fitur teks di atasnya
Sebagai orang yang pernah terlibat dalam pengembangan Mercurial/Sapling, saya percaya LLM bisa meningkatkan ketelitian dengan menunjukkan alternatif yang terlewat tim, tetapi dokumen ini mengecewakan. Keputusannya sendiri punya banyak kelebihan, tapi saya berharap ini menjadi dokumen yang ditulis jauh lebih ketat
2026-06-17 12:56 (Users)
Story: Epic Games announces Lore version control system
Action: changed tags from "release vcs" to "release vcs vibecoding"
Reason: Automatically changed from user suggestions
Apakah ini proyek Rust pertama yang dibuat Epic Games secara terbuka?
Melihat ini dan kabar sistem kontrol versi terbaru dari Cursor, belakangan rasanya semua orang ingin membuat VCS
Apakah cuma saya yang pikiran pertamanya adalah “bukankah ini seharusnya dihosting di atas lore?”