- Epic Games द्वारा मेंटेन किया जाने वाला Lore एक अगली पीढ़ी का ओपन सोर्स version control system है, जिसे ऐसे प्रोजेक्ट्स के लिए बनाया गया है जो code और बड़े binary assets को साथ में संभालते हैं
- यह लोकल में तेज़ी से शुरू किया जा सकता है और ज़रूरत के अनुसार scale किया जा सकता है, तथा shared·reusable data और ज़रूरत पड़ने पर डाउनलोड के ज़रिए बड़े repositories और teams को support करता है
- यह एक केंद्रीकृत content-addressed repository का उपयोग करता है, और Merkle tree तथा immutable revision chain के ज़रिए repository की state और changes history को दर्शाता है
- बड़े files को reusable chunks में स्टोर किया जाता है, और sparse workspace व on-demand hydration की मदद से शुरुआत में सारा data डाउनलोड करना ज़रूरी नहीं होता
- इसे MIT license के तहत जारी किया गया है, और यह CLI, C/C++, C#, Rust, Go, Python, JavaScript API तथा कई SDK repositories प्रदान करता है
code और बड़े assets को साथ में संभालने वाला version control
- Lore Epic Games द्वारा मेंटेन किया जाने वाला अगली पीढ़ी का ओपन सोर्स version control system है
- इसे data scale, team scale, distributed teams और repository scale में उच्च scalability को लक्ष्य बनाकर डिज़ाइन किया गया है
- यह उन projects के लिए optimized है जो code और बड़े binary assets का साथ में उपयोग करते हैं
- उदाहरण के तौर पर game और entertainment industry projects का उल्लेख किया गया है
- यह developers और artists की collaboration आवश्यकताओं को साथ में संभालता है
- इसे local mode में कुछ ही मिनटों में शुरू किया जा सकता है, और बाद में ज़रूरत के अनुसार scale किया जा सकता है
- यह teams को तेज़, सहज और व्यावहारिक collaboration workflows बनाने की बुनियाद देता है
scalability और बड़े files को संभालने के लिए architecture
-
shared data और API
- मुख्य capabilities को scalability और बड़े assets को संभालने के हिसाब से बनाया गया है
- shared·reusable data और ज़रूरत पड़ने पर डाउनलोड के ज़रिए बिना speed घटाए scale करना इसका लक्ष्य है
- branches को तेज़ी से बनाना, manage करना और sync करना संभव है
- CLI के ज़रिए Lore की पूरी functionality तक one-to-one access संभव है
- C/C++, C#, Rust, Go, Python और JavaScript के लिए APIs के माध्यम से extension, customization और integration को support किया जाता है
-
content-addressed repository
- repository architecture एक केंद्रीकृत content-addressed version control system है
- repository data को content hash के आधार पर स्टोर और refer किया जाता है, और इसे Merkle tree के रूप में दर्शाया जाता है
- यह तेज़ comparison, integrity checks, history और branches के बीच data reuse को support करता है
- revision का hash signature parent revision hash और शामिल data hash वाले revision state से derive होता है
- यह structure cryptographic integrity के साथ एक immutable chain बनाता है
-
chunk storage और ज़रूरत पड़ने पर डाउनलोड
- बड़े files और workspace handling के लिए chunk storage और on-demand hydration का उपयोग किया जाता है
- files को reusable chunks में स्टोर किया जाता है और index-based lookup का उपयोग होता है
- इससे duplication कम होती है और बड़े binary assets के updates और transfer अधिक efficient बनते हैं
- workspace केवल ज़रूरी file data लाकर हल्का बना रह सकता है
- sparse workspace के ज़रिए शुरुआत से ही सारा data डाउनलोड करना आवश्यक नहीं है
-
server और branch model
- server architecture caching सहित service-based architecture है
- durable storage के सामने caching के ज़रिए बड़े teams और बड़े repositories के लिए throughput scaling को support किया जाता है
- branches lightweight mutable reference की तरह काम करती हैं, इसलिए उन्हें बनाना और switch करना कम लागत वाला है, और base data duplication नहीं होती
public repositories और documentation
- Epic Games ने Lore को MIT license के तहत पूरी तरह open source के रूप में जारी किया है
- Lore Library, Server & CLI
- Javascript SDK
- Python SDK
- C# SDK
- Go SDK
- documentation और system design document Lore docs तथा system design doc में उपलब्ध हैं
2 टिप्पणियां
Hacker News की राय
जिन HN पाठकों ने कभी गेम नहीं बनाया है, उनके लिए संदर्भ यह है कि यह सामान्य software development में Git से प्रतिस्पर्धा करने वाला टूल नहीं है, बल्कि game development में Perforce से प्रतिस्पर्धा करने वाला टूल है
Git कोड जैसी text-based files के लिए ठीक है, लेकिन textures, 3D models, audio files जैसी non-text files पर collaboration के मामले में बहुत कमजोर है। उदाहरण के लिए, दो artists के asynchronous edits को merge करने का कोई व्यावहारिक तरीका नहीं है, इसलिए किसी asset पर एक artist के edit करते समय exclusive lock लगानी पड़ सकती है
इस क्षेत्र में de facto leader proprietary system Perforce(https://www.perforce.com/products/helix-core) है। game developer दोस्तों के मुताबिक, Perforce जब सही चलता है तो शानदार है, लेकिन इसमें इतने friction points भी हैं कि tool engineers को इसे manage करना पड़ता है और कभी-कभी manually ठीक भी करना पड़ता है। Git LFS भी एक विकल्प है, लेकिन 3~4 लोगों से बड़े team projects में सब Perforce को ज्यादा पसंद करते हैं
P4 में आप access को इस तरह restrict कर सकते हैं कि केवल ज़रूरी NDA पर हस्ताक्षर करने वाले लोग ही किसी specific directory तक पहुंच सकें, लेकिन Git में या तो सबको दे दो या सबको रोक दो जैसा मॉडल है। submodules के साथ कुछ बनाया जा सकता है, लेकिन अगर शुरुआत से इस तरह design न किया गया हो, तो repository structure को काफी बड़े स्तर पर बदलना पड़ता है
git clone, यानीp4 sync, terabytes के स्तर का हो सकता हैGit इस पैमाने के binary assets, textures, models, sounds आदि को संभालने में कमजोर है
अगर development के शुरुआती चरण में कोई asset बार-बार update होता है, तो उसकी storage cost repository की पूरी lifetime भर उठानी पड़ती है। game development में यह आम बात है। ज़्यादातर assets शुरुआत में कई बार इधर-उधर होते हैं, और final हो जाने के बाद फिर कभी छुए नहीं जाते
आज Github पर changes push करते समय भी मैं यही सोच रहा था कि Git का UI कितना user-friendly नहीं है
Enumerating objects,Counting objects,Delta compression,Writing objects,pack-reused,Resolving deltasजैसे outputs कट्टर Git users के लिए कुछ मतलब रखते होंगे, लेकिन ज़्यादातर लोगों के लिए यह पूरी तरह बकवास जैसा है। “delta compression” आखिर है क्या, threads की संख्या क्यों जाननी चाहिए, और “objects”, “local” objects, या “pack-reused” का मतलब क्या है, यह समझना मुश्किल हैdocs देखने पर लगता है कि Lore इस हिस्से को थोड़ा बेहतर संभालता है। यह
Pushing 1 fragment(s),Pushed 1 fragment(s), 124.00 bytes,Pushed revision 1 -> a3f8c2d1... to branch mainजैसा दिखता है-vजैसे verbose output option के पीछे होनी चाहिए, इस पर शायद सब सहमत होंगे। शायद बस किसी ने इसे छुआ नहीं, और दशकों से लोगों ने इसे नज़रअंदाज़ करना सीख लियाobjects को trees refer करते हैं, और tree बस एक directory होती है। उन trees को फिर commits या tags refer करते हैं, जिससे एक DAG बनता है, और उन कई points की तरफ इशारा करने वाले named pointers branch और tag refs होते हैं: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
ढेर सारे loose objects रखना बहुत inefficient है, इसलिए Git समय-समय पर objects को packs में बांध देता है। space बचाने के लिए pack के अंदर objects को एक-दूसरे से compare करके compress किया जाता है, यही delta compression है: https://git-scm.com/docs/git-pack-objects, https://github.com/git/git/blob/master/Documentation/technic...
push या pull करते समय Git transport protocol यह enumerate करता है कि दोनों तरफ कौन-कौन से objects हैं, और केवल फर्क ही transfer करता है। इसके अलावा जो objects अभी pack नहीं हुए हैं, उन्हें भी दोनों तरफ delta compression करके space बचाई जाती है: https://github.com/git/git/blob/master/Documentation/technic...
Git geeks द्वारा बनाया गया open source project है, इसलिए यह सारी जानकारी दिखाता है। आप इसे बस ignore कर सकते हैं। अगर सच में जानना हो, तो ऊपर link की गई Git book और documentation directory में यह सब documented है
अब धीरे-धीरे बात समझ में आने लगी है। UI के नज़रिए से यह Git पर बड़ा improvement है। हालांकि branch workflow का आदी होने में थोड़ा समय लगता है
मैं
.gitdirectory को सीधे खोलकर देखने की ज़ोरदार सिफारिश करता हूं। इससे नए कर्मचारियों के लिए Git support की ज़रूरत लगभग शून्य के करीब आ जाती हैयह घोषणा खासकर Unreal गेम डेवलपमेंट के लिए बहुत आशाजनक लगती है। दूसरे उपयोगों के लिए इतनी दिलचस्पी नहीं है।
Perforce को निश्चित रूप से एक प्रतिस्पर्धी चाहिए। Perforce के मौजूदा दिग्गज होने की वजह यह नहीं है कि उसका उपयोग या प्रबंधन असाधारण रूप से सरल है। उदाहरण के लिए, सिर्फ branch workflow देखें तो Git वास्तव में उससे कहीं ज़्यादा सरल है।
गेम डेवलपमेंट में P4 को अक्सर इसलिए पसंद किया जाता है क्योंकि बड़े प्रोजेक्ट्स का समर्थन, permissions, file locking जैसी बातें—जिनका ज़िक्र दूसरे comments में भी हो चुका है—उसमें मजबूत हैं। एक और अहम वजह यह है कि Unreal Engine के अंदर P4 का support बहुत अच्छा है। यह परफेक्ट नहीं है, लेकिन Epic के अंदरूनी इस्तेमाल का टूल होने की वजह से यह सबसे बेहतर supported version control system है। Git plugin, क्योंकि Epic उसे अंदरूनी तौर पर इस्तेमाल नहीं करता, तकलीफ़देह स्तर तक अधूरा है।
इसलिए उम्मीद है कि Lore को first-class support मिलेगा। अगर Unreal का support बेहतर होता, तो मैं Git की सिफारिश कहीं ज़्यादा करता। संदर्भ के लिए, मैं लगभग 20 साल से गेम डेवलपमेंट में हूँ और 2 लोगों से लेकर 200 लोगों तक की कंपनियों, तरह-तरह के engines और version control systems के साथ काम कर चुका हूँ। जहाँ संभव हो, मैं Git को पसंद करता हूँ, लेकिन Unreal में आमतौर पर तभी जब प्रोजेक्ट छोटा हो या टीम के सदस्य तकनीकी रूप से काफी सक्षम हों। बस काम और टीम के हिसाब से सही टूल चुनना चाहिए।
https://github.com/EpicGames/UnrealEngine/pull/14630
पिछले गेम स्टूडियो में हमें Perforce, या ज़्यादा सटीक कहें तो Helix Core Cloud, इस्तेमाल करना पड़ता था, और ज़्यादातर creative roles के लोग पहले से ही इससे परिचित थे क्योंकि यह लगभग उद्योग का de facto standard है। Programmers को यह पसंद नहीं आता, लेकिन गेम इंडस्ट्री में नियंत्रण programmers के हाथ में नहीं होता। Unreal Engine 5 के साथ इस्तेमाल के लिए यह सुरक्षित और परखा हुआ default है।
लेकिन इसमें पुरानापन साफ दिखता है। हम छोटे थे और self-hosting नहीं चाहते थे, इसलिए शुरू में Perforce की cloud service ली थी, और अनुभव काफी अटकता-भटकता रहा। Service तक पहुँचने के लिए Azure account बनाना पड़ता था, और triggers जैसी चीज़ें बदलने के लिए support team से कहना पड़ता था। अगर आप GitHub या दूसरे SaaS products की दुनिया से आते हैं, तो साफ लगता था कि यह पुराने मॉडल पर नया खोल चढ़ाने की कोशिश है।
Git LFS वाला रास्ता भी कुछ हद तक अनौपचारिक support के साथ मौजूद है, लेकिन अगर चीज़ें बिगड़ जाएँ तो आपको खुद ही संभालना पड़ता है। Epic इसमें ज़्यादा मदद नहीं करता। खासकर अगर engine में पूरी आधिकारिक support का लक्ष्य हो, तो इस क्षेत्र में प्रतिस्पर्धा का आना स्वागतयोग्य है।
टेक्स्ट-आधारित डेवलपमेंट से आने वालों के लिए मैंने इस बारे में लिखा है कि गेम डेवलपमेंट की दुनिया में file merging आम क्यों नहीं है: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
मैंने अभी-अभी एक ऐसी टीम संभाली है जो Git इस्तेमाल कर रही थी। मुझे पता है कि Git सबका पसंदीदा version control system है, लेकिन गेम्स के लिए यह लगभग सबसे खराब विकल्पों में से एक है। Git के साथ art review का समय घंटों में मापना पड़ता था, जबकि Perforce में वह सेकंडों में हो जाता है। यह मज़ाक नहीं है।
UE5 जिन दिलचस्प टूल्स का इस्तेमाल करता है, जैसे Horde या UBA, वे Perforce मांगते हैं।
लेकिन Perforce ने अपनी उद्योग स्थिति पाकर लगभग कुछ नहीं किया। यह बहुत महंगा है, और hosted operations लागत का सवाल भी नहीं है। इसे खुद host करना पड़ता है, और performance के लिहाज़ से भी वही बेहतर है, लेकिन पहली installation के बाद maintenance सचमुच दर्दनाक है। कुछ करने की कोशिश के संकेत दिखते हैं, लेकिन कोई साफ दिशा नहीं है, और उन्होंने जो भी लगभग किया है वह common sense या user base—दोनों से कटा हुआ लगता है। मुख्य product का नाम बार-बार बदलता रहता है, असली सुधार नहीं होते।
यह इस बात का सबक है कि proprietary software कैसे जेल बन सकता है। मैं Swarm से बेहतर code review tool इस्तेमाल करना चाहता हूँ, अपने machine पर segfault कराने वाले अजीब LUA hooks के बिना SSO integrate करना चाहता हूँ, और विशाल SSDs व journal backups पर निर्भर रहने के बजाय distributed storage backend चलाना चाहता हूँ। यहाँ तक कि license भी main server के IP address से बँधा होता है, इसलिए backup recovery तक नहीं हो पाती।
यह भुला दी गई तकनीक है, और इसे चलाने वाली कंपनी लगभग ज़ॉम्बी जैसी लगती है।
यह साफ नहीं है कि permissions वाली समस्या सुलझ गई है या नहीं, या file-level checkout और पारंपरिक branch-based workflow के बीच interaction वाला यह मिश्रित distributed/centralized version control model वास्तव में व्यवस्थित किया गया है या नहीं।
FAQ देखने पर पता चलता है कि यह वास्तव में पूरी तरह नया प्रोडक्ट नहीं है, बल्कि अब जाकर open source किया गया है
इसमें यह विवरण है: “पहले Unreal Revision Control कहलाने वाला Lore, UEFN(Unreal Editor for Fortnite) में built-in version control system है, और creators इसका उपयोग अपनी island versions को मैनेज करने के लिए करते रहे हैं। Epic की internal teams भी इसे धीरे-धीरे अपना रही हैं, और इसे UEFN के cook pipeline backend store के रूप में implement किया जा रहा है, ताकि मौजूदा intermediate storage layer को replace करके duplicate file transfers को खत्म किया जा सके और changes publish होने के बाद playable बनने तक का समय काफी कम किया जा सके।”
Epic के लिए यह C++ या Verse नहीं बल्कि Rust में होना चौंकाने वाला है। वजह जानने की उत्सुकता है
Verse की बजाय Rust इसलिए चुना गया होगा क्योंकि यह काम शायद Verse के लिए उपयुक्त नहीं था। Simon चाहे Verse पर काम कर रहे हों, तब भी। Haskell की बजाय Rust शायद performance की वजह से चुना गया होगा। DARCS भी performance issues की वजह से व्यापक रूप से स्थापित नहीं हो पाया
ऊपर से फिर यह खुद को engine की तमाम समस्याओं और धीमेपन से भी बाँध लेगा। Epic यह गलती Epic Games Launcher में कर चुका है। वह असल में engine instance चलाने जैसा है, और कई समस्याओं का बड़ा स्रोत है
Verse और Rust की तुलना करें तो, Verse UEFN experience के भीतर इस्तेमाल होता है, लेकिन अभी production-ready होने से काफी दूर है। और मूल रूप से UEFN से बँधा हुआ भी है। ऐसा भी नहीं है कि आप कोई standalone compiler या REPL डाउनलोड कर सकें
हाँ, अगर इसे development बंद करने के इरादे से public किया जा रहा हो तो अलग बात है, लेकिन यहाँ मामला वैसा नहीं लगता
Full-surface API एक ऐसी feature है जिसका यहाँ किसी ने जिक्र नहीं किया। सोच रहा हूँ क्या यह Git पर निशाना साधने वाली बात है, क्योंकि Git जानबूझकर linkable library उपलब्ध नहीं कराता। मैंने पहले यह पोस्ट देखी थी: https://news.ycombinator.com/item?id=48470604
porcelainहै। वह linkable form में नहीं है, लेकिन फिर भी API तो हैमूल धारणा यह है कि Git-LFS अच्छा नहीं है, इसलिए एक नया data version control system Rust में scratch से बनाना चाहिए। मैं इस धारणा से काफी हद तक सहमत हूँ, लेकिन internally मिलते-जुलते तरीके इस्तेमाल करने वाले mature existing data version control systems पहले से काफी हैं
Pachyderm(Go): https://github.com/pachyderm/pachyderm
XetHub(HuggingFace ने acquire किया): https://huggingface.co/blog/xethub-joins-hf
LakeFS(Go): https://github.com/treeverse/lakeFS
Oxen(Rust): https://github.com/Oxen-AI/Oxen
लगता है अब AI की बदौलत हर कोई Rust में content-addressing, chunk-level deduplication और version control system की vibe coding कर सकता है
मजाक अपनी जगह, Lore सच में काफी शानदार लग रहा है। दिलचस्प बात यह है कि अलग-अलग domains और industries में समस्याएँ मिलती-जुलती होने के बावजूद ideas का आदान-प्रदान ज्यादा नहीं दिखता। इस मामले में AI और gaming, दोनों को बड़े large binary file versioning storage systems की जरूरत है। ideas share करने के मौके काफी लगते हैं, और यह भी संभव है कि अभी कम sharing होना खुद एक opportunity हो
सिर्फ यही अंतर अलग storage architectures की जरूरत पैदा कर सकता है
मुझे लगता है समस्या का एक हिस्सा Git खुद था, और hybrid repository बनाए रखने के लिए जरूरी compromises भी। इसलिए यह देखकर अच्छा लगता है कि यह version control system Git का इस्तेमाल नहीं करता। xethub ने भी Git के बिना वाला version निकालना शुरू किया था, लेकिन मुझे उसे आजमाने का मौका नहीं मिला
मैंने oxen भी इस्तेमाल किया था, शुरुआत में बुरा नहीं लगा, लेकिन जल्द ही repository state से जुड़े कुछ अजीब issues मिले और मैंने गहराई से debug नहीं किया। इन सभी systems को देखने के बाद यह साफ हो गया कि इनमें से कोई भी 100% संतोषजनक नहीं है, और Git for data कोई मामूली समस्या नहीं है
संदेह है कि कोई कंपनी इस system को सच में, मान लीजिए, 2 साल के भीतर deploy करेगी
Helix और Perforce दशकों से यह काम कर रहे हैं और यह उनके core business का हिस्सा है, इसलिए उन पर भरोसा किया जा सकता है। यह भी पता है कि वे आगे भी कुछ समय तक product को maintain करेंगे
लेकिन Epic अगर कल इस project को छोड़ भी दे, तो उसके business पर कुछ खास असर नहीं पड़ेगा। उल्टा development resources वापस मिलेंगे, जो business के लिए फायदेमंद भी हो सकता है
यह कुछ वैसा ही सवाल है जैसा यह पूछना कि Cloudflare लंबे समय तक EmDash में निवेश क्यों जारी रखेगा। Cloudflare की CMS में दिलचस्पी नहीं है। readers, authors और site owners को सबसे अच्छा experience देना उनका business नहीं है। यह उनके core work से लगभग असंबंधित side project जैसा है
इस क्षेत्र में पहले से अब तक PlasticSCM जैसा एक काफी अच्छा competitor रहा है। कुछ साल पहले Unity ने इसे acquire किया था, लेकिन Unity अच्छा steward साबित नहीं हुआ
Epic की तरह इसे open source करना चाहिए था, लेकिन उसकी जगह P&L responsibility थोपने का रास्ता चुना गया। सोचता हूँ यह Unity की finances में आखिर कितना योगदान दे रहा होगा
Lobste.rs की राय
अगर इसे कोड और बड़े बाइनरी assets को साथ में संभालने वाले गेम/एंटरटेनमेंट प्रोजेक्ट्स के लिए optimize किया गया है, तो लगता है आखिरकार कोई Perforce के दशकों पुराने एकाधिकार से तंग आकर कुछ बना ही रहा है
जब मैंने इसे पहली बार देखा था तब शायद ऐसा नहीं था, लेकिन अब इस पर vibecoding टैग क्यों लगा है, यह जानने की जिज्ञासा है
उदाहरण के लिए, “Mercurial और Sapling text history पर केंद्रित हैं और Lore binary-first है” जैसी व्याख्या गलत है। Mercurial भी binary object model के ऊपर text features चढ़ी हुई संरचना है
Mercurial/Sapling development में शामिल रह चुके व्यक्ति के तौर पर, मुझे लगता है कि LLM टीम से छूटे हुए alternatives की ओर इशारा करके rigor बढ़ा सकता है, लेकिन यह दस्तावेज़ निराशाजनक लगा। फैसले अपने-आप में काफ़ी अच्छे हैं, लेकिन काश यह ज़्यादा rigor से लिखा गया दस्तावेज़ होता
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
क्या यह शायद Epic Games का सार्वजनिक रूप से जारी पहला Rust project है?
इसे और Cursor के हालिया version control system वाले अपडेट को देखकर लगता है कि आजकल हर कोई VCS बनाना चाहता है
क्या सिर्फ़ मेरे मन में पहले यही आया कि “इसे lore पर ही host नहीं होना चाहिए?”