Graphite डेवलपर Greg Foster की इसमें रुचि क्यों हुई
- उन्होंने Facebook के आंतरिक टूल्स से प्रेरित होकर Graphite प्रोजेक्ट शुरू किया
- Facebook के पूर्व सहकर्मियों ने उन्हें Mercurial और "stacked diffs" workflow के बारे में बताया, जिसके बाद उन्होंने इसे GitHub डेवलपर्स के लिए अपनाने का फैसला किया, और नतीजतन Hg के विचारों को Git में एकीकृत करने वाला CLI बनाया
- Facebook ने Git की जगह Mercurial क्यों अपनाया और उसके ऊपर custom workflow क्यों बनाया?
- Google भी Git का उपयोग नहीं करता, लेकिन उसका कारण यह है कि Google की engineering, Git से 5 साल से भी अधिक आगे थी
- दूसरी ओर Facebook की स्थापना 2004 में हुई थी, लगभग उसी समय जब Git बनाया गया था, और जब Facebook ने source control tools का गंभीरता से मूल्यांकन करना शुरू किया, तब Mercurial की तुलना में Git अधिक लोकप्रिय था
- फिर Facebook Git का उपयोग क्यों नहीं करता?
- उनके विचार में, अगर Facebook ने Git अपनाया होता और 2010 के शुरुआती वर्षों में उसमें योगदान दिया होता, तो engineering की दुनिया अलग होती
- शायद Git अधिक user-friendly होता और native रूप से Stacked Changes को support करता
- Facebook के शुरुआती कर्मचारियों द्वारा बनाई गई Uber और Pinterest जैसी कंपनियाँ भी Mercurial की जगह Git और GitHub को source control के रूप में इस्तेमाल करतीं, जिससे पिछले 10 वर्षों में कम fragmented ecosystem बनता
- लेकिन Facebook ने (अपने मुख्य monorepository के लिए) Git पर टिके रहना नहीं चुना। इसके बजाय उसने version control के लिए Mercurial अपनाया और उसके ऊपर धीरे-धीरे custom tools जोड़े
- उन्हें Facebook पर प्रकाशित Scaling Mercurial at Facebook लेख मिला
- यह 10 साल पुराना लेख है, और बाद में कुछ YouTube वीडियो के जरिए उन्हें इसका जवाब मिला: "performance की वजह से"
- लेकिन वे इससे भी गहराई में जाकर उस समय निर्णय लेने वालों की सोच समझना चाहते थे, इसलिए उन्होंने Mercurial migration project में शामिल दो engineers से बात की
- उनके साथ हुई अनौपचारिक बातचीत के आधार पर यह सामग्री संकलित की गई
Facebook ने Git छोड़कर Mercurial पर migration क्यों किया
- Facebook ने शुरुआत में Git का उपयोग किया, लेकिन 2012 के आसपास codebase का आकार बढ़ने पर उसे performance समस्याएँ होने लगीं
- Git में files की "stat-ing" प्रक्रिया bottleneck बन गई, और basic Git commands चलने में 45 मिनट से अधिक लगने लगे
- Git maintainers, Facebook की बड़े repository से जुड़ी समस्याओं पर सहयोगी नहीं थे, और उन्होंने इसके बजाय repository को विभाजित करने की सलाह दी
विचार किए गए विकल्प
- 2012 में Git के बहुत अधिक विकल्प नहीं थे, और Facebook ने Perforce जैसे closed-source solutions पर भी विचार किया, लेकिन उनमें technical समस्याएँ थीं
- Mercurial का performance Git के समान था, लेकिन उसकी architecture अधिक साफ-सुथरी और extensible थी
- Facebook टीम ने Mercurial hackathon में भाग लिया और Mercurial की extensibility तथा community की openness से प्रभावित हुई
पूरे engineering संगठन का migration
- Facebook टीम ने बाकी कंपनी को मनाने के लिए Git और Mercurial के commands और workflows के बीच mapping तैयार की, और डेवलपर्स की चिंताओं को सुनने के लिए समय लिया
- migration प्रक्रिया सावधानी से की गई, और अंततः Facebook ने Mercurial पर स्विच किया
- Facebook ने Mercurial के performance को बेहतर बनाने और "stacked diffs" के जरिए code review को parallelize करने जैसी contributions कीं
समापन विचार
- यह कहानी याद दिलाती है कि "कई बड़े तकनीकी फैसले technology नहीं, बल्कि लोग चलाते हैं"
- Facebook ने Mercurial को इसलिए नहीं चुना कि वह Git से बेहतर perform करता था, बल्कि इसलिए कि Mercurial maintainers के साथ सहयोग अधिक खुला था
- पूरे engineering संगठन को मनाने की प्रक्रिया में यह महत्वपूर्ण था कि कोई तकनीक दूसरी से बेहतर है या नहीं, उससे अधिक "सोच-समझकर की गई communication" मायने रखती है
- यह इस बात पर ज़ोर देती है कि "communication और kindness" डेवलपर tools की दुनिया में महत्वपूर्ण मूल्य हैं
2 टिप्पणियां
एक परिचित की कही यह बात याद आ रही है: "ग्राहक को मनाने के लिए खुजली खुजाने वाली पीठ-खुजली स्टिक जैसा बनना पड़ता है"
बहुत ज़्यादा तेज़ होने की ज़रूरत नहीं, बहुत ज़्यादा तेज़-तर्रार होने की भी ज़रूरत नहीं, बहुत ज़्यादा सुविधाजनक होने की भी ज़रूरत नहीं, और बहुत ज़्यादा महँगा होने की भी ज़रूरत नहीं—बस अगर ठीक उसी जगह खुजा दे जिसकी ज़रूरत है, तो वही वह service है जो ग्राहक चाहता है, हाहा
मेरा मानना है कि चूँकि Git को Linus Torvalds ने Linux source code को manage करने के लिए बनाया था, इसलिए उसमें कुछ ऐसे हिस्से रहे होंगे जिन पर आसानी से समझौता नहीं किया जा सकता था.
निष्कर्ष वाले विचार का सार कुछ ऐसा सुनाई देता है मानो Git बुरा है क्योंकि उसने Facebook की अपनी मांगें नहीं सुनीं और communication व friendliness को महत्व नहीं दिया, लेकिन मुझे लगता है कि बात बस इतनी थी कि कई पहलुओं में दोनों की प्रवृत्तियाँ एक-दूसरे से अलग थीं.
उल्टा सोचें तो Facebook के पास Git द्वारा सुझाए गए repository split को स्वीकार करने और उसे लागू करने का विकल्प भी था. बस वह उस तरह की friendliness नहीं थी जो वे चाहते थे.