- Microsoft का बड़े पैमाने का JavaScript monorepo, 1JS, कोड और योगदान की मात्रा के हिसाब से बहुत विशाल है। हाल ही में clone की गई repo का आकार 178GB तक पहुँच गया था।
- repo का आकार इतना बड़ा हो गया था कि यूरोप के कुछ उपयोगकर्ता इसे clone ही नहीं कर पा रहे थे।
सबक #1
- कुछ साल पहले जब लेखक इस repo से जुड़े, तब उन्होंने देखा कि repo बहुत तेज़ी से बढ़ रही थी। पहली बार clone करने पर यह 1~2GB थी, लेकिन कुछ महीनों बाद ही 4GB तक पहुँच गई।
- बड़े blob की जाँच के लिए
git-sizer टूल का उपयोग किया गया, जो आमतौर पर तब बनते हैं जब binaries गलती से check-in हो जाती हैं। इसे रोकने के लिए Azure DevOps की check-in size limit सुविधा का उपयोग किया जा सकता है।
- Beachball change files को delete न करने की वजह से भी समस्या हुई। यह Changesets की तरह packages की semver range को अपने आप बढ़ाने के लिए इस्तेमाल होता है।
- इससे यह सबक मिला कि एक ही folder में हज़ारों files नहीं रखनी चाहिए। इसे हल करने के लिए Beachball में कई changes को एक file में संभालने वाला pull request भेजा गया, और change folder को समय-समय पर साफ़ करने के लिए एक pipeline लिखी गई।
सबक #2
main का mirror रहने वाली versioned branch को clone करना लगातार मुश्किल होता जा रहा था। केवल CHANGELOG.md और CHANGELOG.json files बदलने के बावजूद, 125GB अतिरिक्त git data आ रहा था।- यह पाया गया कि Linus Torvalds द्वारा check-in किया गया पुराना packing code compression करते समय file name के सिर्फ़ आख़िरी 16 characters की तुलना करता था। इसके कारण git अलग-अलग packages की
CHANGELOG.md files की आपस में तुलना करता रहा और पूरी files को बार-बार push करता रहा।
git repack -adf --window=250 कमांड से repo का आकार घटाया गया, और नए git repack -adf --path-walk कमांड के इस्तेमाल से इसे 178GB से 5GB तक घटा दिया गया।git push के दौरान सही delta बनें, इसके लिए git config --global pack.usePathWalk true सेटिंग जोड़ी गई।
समापन
- बड़े monorepo में अगर
CHANGELOG.md जैसे लंबे नाम वाली files बार-बार update होती हैं, तो path walk फीचर पर ध्यान देना चाहिए।
git survey कमांड से disk size के हिसाब से सबसे बड़ी files, inflated size के हिसाब से सबसे बड़े directories आदि देखे जा सकते हैं।- Microsoft repository expansion के लिए solutions विकसित कर रहा है और उन्हें दुनिया भर में उपलब्ध करा रहा है।
GN⁺ की संक्षिप्त टिप्पणी
- यह लेख बड़े पैमाने के JavaScript monorepo का git आकार घटाने के व्यावहारिक अनुभव साझा करता है। खास तौर पर, पुराने git packing code की समस्या को हल करके repo का आकार बहुत कम किया गया।
- यह लेख बड़े projects में आने वाली git संबंधी समस्याओं को हल करने के लिए उपयोगी जानकारी देता है। खास तौर पर,
CHANGELOG.md जैसी files के बार-बार update होने से पैदा होने वाली समस्या को हल करने का तरीका समझाता है।
- समान प्रकृति वाले projects में Facebook का Buck और Google का Bazel शामिल हैं। ये tools बड़े codebase को अधिक कुशलता से manage करने में मदद कर सकते हैं।
1 टिप्पणियां
Hacker News राय
नया
git-surveyकमांड अभीgit.gitमें शामिल नहीं है। इसे Microsoft के Git fork में जोड़ा गया हैnixpkgsको clone करते समय,--window 250विकल्प ने आकार को 1.7GB तक घटा दिया। Microsoft Git fork का--path-walkविकल्प इसे 1.9GB तक ले आयायूरोप के कुछ users का कहना है कि वे बड़े repository को clone नहीं कर सकते। लगता है कि server side पर बदलाव होने तक clone करना संभव नहीं होगा
file name में पूरा path शामिल न होने की गलती की वजह से समस्या हुई। केवल आख़िरी 16 characters देखे जा रहे थे
Derick Stolee ने Git की internal structure पर एक blog लिखा है। उससे local और CI में
git cloneका आकार कम करने के तरीकों के बारे में बहुत कुछ सीखा जा सकता हैGit को hack करना मज़ेदार है, लेकिन यह सोचने वाली बात है कि क्या 2,500 packages को monorepo में शामिल न करने का कोई तरीका है
बेहतर होगा कि Microsoft खुद Azure DevOps का इस्तेमाल करे। ऐसा लगता है कि Azure services केवल GitHub के लिए native connectors देती हैं
Git की internal structure को अच्छी तरह जानने वाला कोई व्यक्ति आसपास होना, बड़े project पर काम करते समय एक बड़ा फ़ायदा है
इस पोस्ट के लिए धन्यवाद। इससे open source software को बहुत मदद मिली है। Microsoft, GitHub, और GitLab बहुत-सी अच्छी चीज़ें दे रहे हैं
आख़िरी 16 characters और पूरे path की जाँच वाले मुद्दे को मैं बेहतर समझना चाहता हूँ। यह delta compression, package index, और multi-package index से कैसे जुड़ता है, यह जानने की जिज्ञासा है