Lore – स्केलेबिलिटी के लिए डिज़ाइन किया गया ओपन सोर्स वर्शन कंट्रोल सिस्टम
उद्देश्य और स्थिति
- इसे मुख्यतः गेम डेवलपमेंट और अन्य asset‑heavy workflows के लिए Perforce के विकल्प के रूप में देखा जा रहा है, न कि सामान्य Git प्रतिस्थापन के रूप में।
- लक्षित उपयोगकर्ता: प्रोग्रामर और कलाकारों को मिलाने वाली टीमें, जिनके repos सैकड़ों GB–TB के होते हैं और जिनमें binary assets (textures, models, audio, levels) का प्रभुत्व होता है।
यहाँ Git (और Git LFS) क्यों संघर्ष करते हैं
- Git text/code के लिए उत्कृष्ट है, लेकिन बड़े binaries के लिए कमजोर है:
- Repos और clones तेज़ी से फूले हुए हो जाते हैं; history बहुत बड़ी और धीमी हो जाती है।
- Git LFS locking और indirection जोड़ता है, लेकिन इसे fragile, confusing, और बड़े scale पर configure करना कठिन बताया गया है; बार‑बार auth और corruption issues का ज़िक्र है।
- Fine‑grained permissions नहीं हैं; access repo‑wide होता है, जब तक आप repos को split न करें या awkward submodules का उपयोग न करें।
- Sparse checkout और partial clones मौजूद हैं, लेकिन वे sharp‑edged हैं और कलाकार‑अनुकूल नहीं हैं।
- Git का CLI और output व्यापक रूप से confusing और अत्यधिक verbose माना जाता है, विशेषकर non‑engineers के लिए।
Lore कैसे मदद करने का दावा करता है
- बड़े binary assets को ध्यान में रखकर डिज़ाइन किया गया है:
- Deduplication और तेज़ partial transfers के लिए chunked storage।
- On‑demand hydration / sparse working copies ताकि उपयोगकर्ता केवल वही assets खींचें जिनकी उन्हें ज़रूरत है।
- Non‑mergeable assets के concurrent edits रोकने के लिए native file locking।
- Per‑directory/asset permissions और multi‑tenant isolation।
- Developers के लिए Git‑like CLI; artists के लिए GUI desktop client का वादा किया गया है (binary अभी उपलब्ध है, source बाद में खोला जाएगा)।
- Git की “no library” स्थिति के विपरीत, पूरा API surface intended है।
Centralization, scale, और architecture
- Lore स्पष्ट रूप से centralized है (Git की तुलना में Perforce जैसा); peer‑to‑peer एक non‑goal है।
- Unreal Engine/UEFN pipelines जैसी चीज़ों को support करने के लिए डिज़ाइन किया गया; कहा गया है कि इसका उपयोग पहले से ही Fortnite content के लिए internal रूप से हो रहा है।
- Multi‑region deployments अभी AWS services जैसे DynamoDB पर निर्भर हैं, जिससे cloud coupling को लेकर चिंताएँ हैं।
Tooling, UX, और adoption संबंधी चिंताएँ
- कई लोग ज़ोर देते हैं कि आज UE और Perforce साथ मिलकर अच्छी तरह काम करते हैं; migration inertia बहुत अधिक है क्योंकि कलाकार नए tools सीखना पसंद नहीं करते।
- Lore की सफलता को Unreal, Unity, DCC tools (Maya, Blender, आदि) के साथ गहरे integration और एक polished GUI पर निर्भर माना जा रहा है।
- कुछ लोग पूछते हैं कि क्या Lore plain text/code के लिए इतना अच्छा है कि पूरे org में Git को replace कर सके; अन्य Git tooling के इर्द‑गिर्द ecosystem lock‑in को नोट करते हैं।
Epic पर भरोसा और project maturity
- core infrastructure को Epic से जोड़ने पर skepticism:
- पिछले निर्णय (जैसे games के लिए Linux/macOS support छोड़ना, Epic Store controversies) trust issues के रूप में उद्धृत किए गए।
- डर है कि MIT licensing के बावजूद Lore को abandoned किया जा सकता है या एक “open core” upsell में बदला जा सकता है।
- Docs और design pages को व्यापक रूप से LLM‑generated, verbose, और पढ़ने में कठिन माना गया है; इससे rigor पर भरोसा कम होता है, भले ही underlying system solid हो सकता है।
- कुछ लोगों का कहना है कि अपनी FAQ के अनुसार यह अभी “production‑ready” नहीं है; कई लोग अधिक real‑world reports का इंतज़ार करेंगे।
व्यापक उपयोगिता और तुलना
- अन्य domains (ML/AI datasets, CAD, 3D modeling, photography, PDM/PLM) में binary‑first VCS की संभावनाएँ दिखती हैं।
- Existing data/BLOB tools (git‑annex, DVC, lakeFS, Pachyderm, Oxen, XetHub) और अन्य VCSs (Mercurial, SVN, PlasticSCM, Diversion, jj, Pijul) की तुलना में; consensus यह है कि “Git for data/gamedev” अभी भी एक कठिन unsolved problem है, इसलिए अधिक experimentation का स्वागत है।