- Epic Games tarafından geliştirilen Lore, kodu ve büyük ikili varlıkları birlikte yöneten projeleri hedefleyen yeni nesil açık kaynak bir sürüm kontrol sistemidir
- Yerelde hızlıca başlayıp ihtiyaç oldukça ölçeklenebilir; paylaşılan ve yeniden kullanılan veri ile ihtiyaç anında indirme yaklaşımı sayesinde büyük depoları ve ekipleri destekler
- Merkezi içerik adreslemeli depo kullanır; depo durumu ve değişiklik geçmişini Merkle tree ve değiştirilemez revision chain ile ifade eder
- Büyük dosyalar yeniden kullanılabilir chunk'lar olarak saklanır; sparse workspace ve on-demand hydration sayesinde en başta tüm veriyi indirmek gerekmez
- MIT lisansı ile yayımlandı; CLI, C/C++, C#, Rust, Go, Python, JavaScript API'leri ve çeşitli SDK depoları sunar
Kod ve büyük varlıkları birlikte yöneten sürüm kontrolü
- Lore, Epic Games tarafından geliştirilen yeni nesil açık kaynak bir sürüm kontrol sistemidir
- Veri ölçeği, ekip büyüklüğü, ekip dağılımı ve depo boyutu açısından yüksek ölçeklenebilirlik hedefiyle tasarlanmıştır
- Kod ile büyük ikili varlıkları birlikte kullanan projeler için optimize edilmiştir
- Oyun ve eğlence sektörü projeleri örnek olarak verilmektedir
- Geliştiriciler ile sanatçıların iş birliği ihtiyaçlarını birlikte ele alır
- Yerel modda birkaç dakika içinde başlanabilir, ardından ihtiyaç oldukça ölçeklenebilir
- Ekiplerin hızlı, sezgisel ve pratik iş birliği iş akışları kurabilmesi için temel sağlar
Ölçeklenebilirlik ve büyük dosya işleme için yapı
-
Paylaşılan veri ve API
- Temel özellikler ölçeklenebilirlik ve büyük varlık işleme odağıyla tasarlanmıştır
- Paylaşılan ve yeniden kullanılabilir veri ile ihtiyaç anında indirme sayesinde hız kaybı olmadan ölçeklenmeyi hedefler
- Branch'ler hızlıca oluşturulabilir, yönetilebilir ve senkronize edilebilir
- CLI üzerinden Lore'un tüm işlevlerine bire bir erişim mümkündür
- C/C++, C#, Rust, Go, Python ve JavaScript için API'ler; genişletme, özelleştirme ve entegrasyonu destekler
-
İçerik adreslemeli depo
- Depo yapısı, merkezi bir content-addressed sürüm kontrol sistemidir
- Depo verileri içerik hash'i ile saklanır ve referanslanır, Merkle tree ile temsil edilir
- Hızlı karşılaştırma, bütünlük denetimi, geçmiş ile branch'ler arasında veri yeniden kullanımını destekler
- Revision'ın hash imzası, üst revision hash'i ile içerdiği veri hash'lerini kapsayan revision durumundan türetilir
- Bu yapı, kriptografik bütünlüğe sahip değiştirilemez bir zincir oluşturur
-
Chunk depolama ve ihtiyaç anında indirme
- Büyük dosya ve workspace işlemleri chunk depolama ve on-demand hydration kullanır
- Dosyalar yeniden kullanılabilir chunk'lar olarak saklanır ve indeks tabanlı erişim kullanılır
- Tekrarı azaltır, büyük ikili varlıkların güncellenmesini ve aktarımını verimli hale getirir
- Workspace, yalnızca gerekli dosya verisini alarak hafif tutulabilir
- Sparse workspace sayesinde en başta tüm veriyi indirmek gerekmez
-
Sunucu ve branch modeli
- Sunucu yapısı, önbellekleme içeren servis tabanlı bir mimaridir
- Kalıcı depolamanın önündeki önbellekleme, büyük ekipler ve büyük depolarda işlem hacminin ölçeklenmesini destekler
- Branch'ler hafif mutable reference olarak çalışır; oluşturma ve geçiş maliyeti düşüktür, varsayılan veri kopyası yoktur
Açık depolar ve belgeler
- Epic Games, Lore'u MIT lisansı ile tamamen açık kaynak olarak yayımladı
- Lore Library, Server & CLI
- Javascript SDK
- Python SDK
- C# SDK
- Go SDK
- Belgeler ve sistem tasarım dokümanları Lore docs ve system design doc üzerinden sunulmaktadır
2 yorum
Hacker News görüşleri
Oyun oynamamış HN okurları için biraz bağlam ekleyeyim: bu, genel yazılım geliştirmede Git ile rekabet etmeye çalışan bir araç değil, oyun geliştirmede Perforce ile rekabet etmeye çalışan bir araç
Git, kod gibi metin tabanlı dosyalarda fena değildir ama doku, 3D model, ses dosyası gibi metin dışı dosyalarda işbirliği açısından çok zayıftır. Örneğin iki sanatçının eşzamansız düzenlemelerini birleştirmenin makul bir yolu yoktur; bu yüzden bir sanatçının düzenlediği asset üzerine özel kilit koymak gerekebilir
Bu alanın fiili lideri, tescilli bir sistem olan Perforce'tur(https://www.perforce.com/products/helix-core). Oyun geliştirici arkadaşlarımın anlattığına göre Perforce düzgün çalıştığında harika, ama araç mühendislerinin yönetmesi ve ara sıra elle düzeltmesi gerekecek kadar sürtünme de çıkarabiliyor. Git LFS de bir alternatif, ancak 3-4 kişiden büyük takım projelerinde herkes Perforce'u daha çok tercih ediyor gibi
P4'te gerekli NDA'leri imzalayan kişilerin belirli dizinlere erişimini kısıtlayabilirsiniz, ama Git'te ya her şeyi verirsiniz ya da tamamen engellersiniz. Submodule ile bir şeyler kurulabilir ama en baştan öyle tasarlanmadıysa depo yapısını ciddi biçimde altüst etmek gerekir
git clone, yanip4 sync, işleminin terabaytlar düzeyinde olabileceğini anlamak gerekiyorGit, bu ölçekteki ikili asset'leri, dokuları, modelleri, sesleri vb. ele almakta zayıf
Geliştirmenin erken aşamalarında sık sık güncellenen asset'ler varsa, deponun ömrü boyunca o depolama maliyetini taşımak zorunda kalırsınız. Oyun geliştirmede bu çok yaygındır. Asset'lerin çoğu başlarda birkaç kez gidip gelir, tamamlandıktan sonra ise bir daha dokunulmaz
Bugün Github'a değişiklikleri push ederken bile Git'in arayüzünün ne kadar kullanıcı dostu olmadığını düşündüm
Enumerating objects,Counting objects,Delta compression,Writing objects,pack-reused,Resolving deltasgibi çıktılar, koyu Git kullanıcılarına bir şey ifade ediyor olabilir ama çoğu insan için tam bir anlamsız laf kalabalığı. “Delta compression” tam olarak nedir, neden kaç thread kullanıldığını bilmem gerekiyor, “objects” ya da “local” objects ve “pack-reused” ne anlama geliyor, anlamak zorDokümanlara bakınca Lore bu kısmı biraz daha iyi ele alıyor gibi görünüyor.
Pushing 1 fragment(s),Pushed 1 fragment(s), 124.00 bytes,Pushed revision 1 -> a3f8c2d1... to branch mainşeklinde görünüyor-vgibi bir ayrıntılı çıktı seçeneğinin arkasında olmalı, konusunda herkes hemfikir olabilir gibi. Muhtemelen kimse el atmadı ve biz de onlarca yıl boyunca onu görmezden gelmeyi öğrendikObject'lere tree'ler referans verir, tree de aslında dizindir. Tree'lere de commit ya da tag referans vererek bir DAG oluşturur; bu yapının çeşitli noktalarını gösteren adlandırılmış işaretçiler ise branch ve tag referanslarıdır: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Çok sayıda loose object tutmak oldukça verimsiz olduğundan Git, object'leri düzenli olarak pack içine toplar. Alandan tasarruf etmek için pack içindeki object'ler birbirleriyle karşılaştırılarak sıkıştırılır; buna delta compression denir: https://git-scm.com/docs/git-pack-objects, https://github.com/git/git/blob/master/Documentation/technic...
Push ya da pull sırasında Git aktarım protokolü, iki tarafın hangi object'lere sahip olduğunu listeleyip yalnızca farkı gönderir. Buna ek olarak henüz pack içine alınmamış object'ler iki tarafta da delta compression ile sıkıştırılarak yer tasarrufu sağlanır: https://github.com/git/git/blob/master/Documentation/technic...
Git, inekler tarafından yapılmış bir açık kaynak proje olduğu için bütün bu bilgileri gösterir. Görmezden gelseniz de olur. Gerçekten öğrenmek isterseniz yukarıda bağlantısı verilen Git kitabında ve doküman dizininde hepsi belgelenmiş durumda
Yavaş yavaş mantıklı gelmeye başladı. Arayüz açısından Git'e göre büyük bir gelişme. Yalnız branch iş akışına alışmak biraz zaman alıyor
.gitdizinine bizzat göz atmayı şiddetle tavsiye ederim. Bunu yaptığınızda yeni çalışanlar için Git desteği ihtiyacı fiilen sıfıra yaklaşıyorBu duyuru özellikle Unreal oyun geliştirme için çok umut verici. Diğer kullanım alanları içinse o kadar ilgimi çekmiyor.
Perforce’un kesinlikle bir rakibe ihtiyacı var. Perforce’un mevcut güçlü oyuncu olmasının nedeni kullanım veya yönetim açısından olağanüstü derecede basit olması değil. Örneğin yalnızca branch işlemlerine bakarsanız Git aslında çok daha basit.
Oyun geliştirmede P4’ün sık tercih edilmesinin nedeni, diğer yorumlarda da geçtiği gibi büyük projeleri desteklemesi, yetkiler ve dosya kilitleme gibi özellikler. Bir diğer temel neden de P4’ün Unreal Engine içinde çok iyi desteklenmesi. Kusursuz değil ama Epic’in içeride kullandığı araç olduğu için en iyi desteklenen sürüm kontrol sistemi. Git eklentisi ise Epic tarafından şirket içinde kullanılmadığından, can sıkacak derecede yarım kalmış durumda.
Bu yüzden Lore’un birinci sınıf destek almasını bekliyorum. Unreal desteği daha iyi olsaydı Git’i çok daha fazla önerirdim. Arka plan olarak, yaklaşık 20 yıldır oyun geliştiriyorum; 2 kişilik ekiplerden 200 kişilik şirketlere kadar, her türlü motor ve sürüm kontrol sistemiyle çalıştım. Mümkün olan yerlerde Git’i tercih ederim ama Unreal’da ancak küçük projelerde veya teknik olarak güçlü ekip arkadaşları olduğunda. Yapılması gereken, işe ve ekibe uygun aracı seçmek.
https://github.com/EpicGames/UnrealEngine/pull/14630
Önceki oyun stüdyomuzda Perforce, daha doğrusu Helix Core Cloud kullanmak zorundaydık; yaratıcı rollerde çalışanların çoğunun zaten aşina olduğu fiili sektör standardı bu. Programcılar bundan hoşlanmıyor ama oyun sektöründe direksiyonda olan taraf programcılar değil. Unreal Engine 5 ile birlikte kullanmak için de güvenli ve kendini kanıtlamış varsayılan seçenek.
Yine de yaşını belli ediyor. Biz küçüktük ve self-hosting istemiyorduk, bu yüzden Perforce’un bulut hizmetini erken dönemde kullananlardandık ama deneyim oldukça pürüzlüydü. Hizmete erişmek için bir Azure hesabı kaydetmeniz gerekiyordu ve trigger gibi şeyleri değiştirmek için destek ekibine başvurmanız gerekiyordu. GitHub ya da diğer SaaS ürünleri dünyasından geliyorsanız, bunun eski bir modele yeni bir kabuk geçirme denemesi olduğu hissediliyordu.
Git LFS tarafında biraz gayriresmî destek var ama işler sarpa sararsa çözümü kendiniz bulmanız gerekiyor. Epic bu konuda pek yardımcı olmuyor. Özellikle motor içinde tam resmî destek hedefleniyorsa, bu alandaki rekabet memnuniyet verici olur.
Metin tabanlı geliştirmeden gelenler için, oyun geliştirme dünyasında dosya birleştirmenin neden yaygın olmadığını anlatan bir yazı yazmıştım: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
Az önce Git kullanan bir ekibi devraldım; Git’in herkesin sevdiği sürüm kontrol sistemi olduğunu biliyorum ama oyunlar için neredeyse mümkün olan en kötü seçeneğe yakın. Git ile sanat inceleme süresini saatle ölçmek zorundaydık, Perforce ile ise saniyelerle ölçülüyor. Şaka değil.
UE5’in kullandığı ilginç araçlar, örneğin Horde veya UBA gibi şeyler, Perforce gerektiriyor.
Ama Perforce sektör konumuna yaslanıp hiçbir şey yapmadı. Aşırı pahalı ve barındırma işletim maliyetleri de yok değil. Kendi başınıza host etmeniz gerekiyor ve performans açısından da bunu kendiniz yapmanız daha iyi, ancak ilk kurulumdan sonra bakım gerçekten çok sancılı. Bir şeyler denediklerine dair izler var ama belirgin bir yön yok; yaptıkları neredeyse her şey sağduyuyla ya da kullanıcı tabanıyla ters düşüyor. Çekirdek ürün sürekli yeniden adlandırılıyor ama gerçek bir iyileşme yok.
Bu, kapalı kaynak yazılımın nasıl bir hapishaneye dönüşebildiğinin ders kitabı örneği. Swarm’dan daha iyi bir kod inceleme aracı kullanmak istiyorum, cihazımda segfault yaratan garip LUA hook’ları olmadan SSO entegre etmek istiyorum ve devasa SSD’lere ve journal yedeklerine bağımlı olmak yerine dağıtık bir depolama backend’i çalıştırmak istiyorum. Hatta lisans ana sunucunun IP adresine bağlı olduğu için yedekten geri dönüş bile yapılamıyor.
Unutulmuş bir teknoloji ve o şirketi işleten yapı da zombi gibi.
Yetki sorunlarının çözülüp çözülmediğini ya da dosya düzeyinde checkout’un geleneksel branch tabanlı çalışmayla nasıl etkileşeceği gibi bu karma dağıtık/merkezî sürüm kontrol modeli meselelerinin netleşip netleşmediğini bilmiyorum.
SSS’ye bakınca bunun aslında tamamen yeni bir ürün değil, ancak şimdi açık kaynak olarak yayımlandığı görülüyor
Şöyle bir açıklama var: “Önceden Unreal Revision Control olarak adlandırılan Lore, UEFN (Unreal Editor for Fortnite) içine gömülü sürüm kontrol sistemi ve içerik üreticileri bunu kendi ada sürümlerini yönetmek için kullanıyordu. Epic iç ekipleri de bunu kademeli olarak benimsiyor; ayrıca UEFN’in cook pipeline backend deposu olarak uygulanıyor, mevcut ara depolama katmanının yerini alarak yinelenen dosya aktarımlarını ortadan kaldırıyor ve değişiklikler yayımlandıktan sonra oynanabilir hale gelene kadar geçen süreyi ciddi ölçüde kısaltıyor.”
Epic C++ ya da Verse değil de Rust kullanmış olması şaşırtıcı. Sebebini merak ediyorum
Verse yerine Rust seçilmesinin nedeni ise muhtemelen o işin Verse’e uygun olmaması. Simon Verse üzerinde çalışıyor olsa bile bu değişmezdi. Haskell yerine Rust seçilmesinin nedeni de büyük olasılıkla performans olurdu. DARCS da performans sorunları yüzünden yaygın olarak yer edememişti
Üstelik kendini motorun türlü sorunlarına ve yavaşlığına da bağlamış olursun. Epic bu hatayı Epic Games Launcher’da yaptı. Bu pratikte bir motor örneği çalıştırmak gibi ve birçok sorunun büyük kaynağı
Verse ile Rust’ı karşılaştırınca, Verse UEFN deneyiminin içinde kullanılıyor ama hâlâ prodüksiyon düzeyinden uzak. Ayrıca doğası gereği UEFN’e bağlı. Bağımsız çalışan bir derleyici ya da REPL indirilebilir durumda değil
Elbette geliştirmeyi bırakmaya karar verdikleri için açıyorlarsa bu başka ama burada öyle görünmüyor
Full-surface API, burada kimsenin değinmediği bir özellik. Bunun, Git’in kasıtlı olarak bağlanabilir bir kütüphane sunmamasına gönderme olup olmadığını merak ediyorum. Daha önce şu yazıyı görmüştüm: https://news.ycombinator.com/item?id=48470604
porcelainvar. Bağlanabilir biçimde değil ama yine de bir APIVarsayım şu: Git-LFS kötü, bu yüzden sıfırdan Rust ile yeni bir veri sürüm kontrol sistemi yapmak gerekiyor. Bu varsayıma genel olarak katılıyorum ama içeride benzer numaralar kullanan olgun mevcut veri sürüm kontrol sistemleri de zaten epey var
Pachyderm(Go): https://github.com/pachyderm/pachyderm
XetHub(HuggingFace tarafından satın alındı): https://huggingface.co/blog/xethub-joins-hf
LakeFS(Go): https://github.com/treeverse/lakeFS
Oxen(Rust): https://github.com/Oxen-AI/Oxen
Görünüşe göre artık yapay zeka sayesinde herkes Rust ile içerik adresleme, parça düzeyinde yineleme kaldırma ve sürüm kontrol sistemi vibe coding yapabiliyor
Şakayı bir kenara bırakırsak, Lore gerçekten çok iyi görünüyor. İlginç olan, farklı alanlar ve sektörlerin benzer sorunlara sahip olmasına rağmen pek fazla fikir alışverişi varmış gibi görünmemesi. Bu örnekte hem yapay zeka hem de oyun tarafı büyük ölçekli büyük ikili dosya sürüm kontrolü depo sistemlerine ihtiyaç duyuyor. Fikir paylaşımı için çok fırsat var gibi ve şu an paylaşımın az olması başlı başına bir fırsat yaratabilir
Sadece bu fark bile farklı depo mimarileri gerektirebilir
git-annexve iterative DVC de var. xethub’ı epey kullandım, hatta erken kullanıcılarından biriydim; bencegit-annex,git-lfsve DVC’den daha iyiydi ama belli bir ölçeğin üstüne çıkınca yine zorlanmaya başladıSorunun bir kısmı bence Git’in kendisi ve hibrit bir depo yapısını sürdürmek için gereken tavizlerdi. O yüzden bu sürüm kontrol sisteminin Git kullanmıyor olması hoşuma gidiyor. xethub da Git kullanmayan bir ürün sürümü çıkarmaya başladı ama deneme fırsatım olmadı
oxen’i de kullandım ve başta fena değildi ama kısa süre sonra depo durumuyla ilgili garip sorunlarla karşılaştım, derinlemesine hata ayıklama yapmadım. Tüm bu sistemleri deneyince hiçbirinin %100 tatmin edici olmadığı ve veri için Git meselesinin ufak bir problem olmadığı netleşiyor
Gerçekten herhangi bir şirketin bu sistemi, örneğin 2 yıl içinde dağıtıp kullanıma alıp almayacağını merak ediyorum
Helix ve Perforce bunu onlarca yıldır yapıyor ve bu onların ana işinin bir parçası olduğu için güvenilebilir. Bir süre daha ürünü bakımda tutacaklarını biliyorsun
Ama Epic yarın bu projeyi bıraksa işine hiçbir şey olmaz. Hatta geliştirme kaynaklarını geri kazanacağı için işine yarayabilir bile
Bu biraz da neden Cloudflare’ın EmDash’e uzun vadede yatırım yapmayı sürdüreceğine inanasın ki sorusuna benziyor. Cloudflare’ın CMS’e ilgisi yok. Okuyuculara, yazarlara ve site sahiplerine en iyi deneyimi sunmak onların işi değil. Asıl işleriyle neredeyse ilgisiz bir yan uğraş gibi
Bu alanda eskiden beri PlasticSCM diye oldukça iyi bir rakip vardı ve hâlâ var. Birkaç yıl önce Unity satın aldı ama Unity iyi bir yönetici olmadı
Epic’in yaptığı gibi bunu açık kaynak yapmaları gerekirdi ama onun yerine kâr-zarar sorumluluğu yükleme yolunu seçtiler. Unity finansallarına ne kadar katkı sağladığını merak ediyorum
Lobste.rs görüşleri
Kod ve büyük ikili varlıkları birlikte yöneten oyun/eğlence projeleri için optimize edildiğine göre, sonunda biri Perforce'un onlarca yıllık tekeline bıkıp bir şey yapmış galiba
İlk gördüğümde yoktu sanırım; neden şimdi vibecoding etiketi eklendiğini merak ediyorum
Örneğin “Mercurial ve Sapling metin geçmişi odaklıyken Lore ikili öncelikli” tarzı bir açıklama yanlış. Mercurial da metin özelliklerinin üzerine kurulduğu ikili nesne modeline sahip
Mercurial/Sapling geliştirmesinde yer almış biri olarak, LLM'lerin ekibin gözden kaçırdığı alternatifleri işaret ederek titizliği artırabileceğine inanıyorum ama bu belge hayal kırıklığı yarattı. Kararın kendisinin pek çok güçlü yanı var ama keşke çok daha titiz yazılmış bir belge olsaydı
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
Acaba bu, Epic Games'in kamuya açık olarak yaptığı ilk Rust projesi mi?
Bunu ve Cursor'un en son sürüm kontrol sistemi haberini görünce, bugünlerde herkes VCS yapmaya çalışıyor gibi geliyor
İlk aklıma gelen şeyin “Bunun lore üzerinde barındırılması gerekmiyor mu?” olması sadece bana mı özgü?