svn - गिट/मर्कुरियल/बाज़ार बनाम की लोकप्रियता जो




git version-control (8)

इन तीन वितरित संस्करण नियंत्रण प्रणालियों के लिए इस साइट पर प्रश्नों की संख्या के आधार पर, यह गिट की तरह लगता है

  1. अधिक लोकप्रिय है, या
  2. अधिक कठिन है (इसलिए अधिक प्रश्नों की आवश्यकता है), या
  3. इसमें अधिक सुविधाएं हैं (इसलिए अधिक प्रश्नों की आवश्यकता है)।

या शायद तीनों का एक संयोजन। (मान लें कि इस साइट पर लोकप्रियता बड़े पैमाने पर लोकप्रियता के बराबर होती है।) यहां संख्याएं हैं:

                | Jun 2009 | Jul 2010 | Jul 2011 | Jul 2012 | Jul 2013 | Jul 2014 | Jul 2015 | Jul 2016 | Jun 2017
    ---------------------------------------------------------------------------------------------------------------
    [svn]       |     2353 |     5323 |     9028 |    12687 |    15587 |    18846 |    21209 |    23037 |    24692
    [git]       |      726 |     3725 |     9225 |    17523 |    27862 |    41478 |    55315 |    71056 |    86958
    [mercurial] |      169 |     1120 |     2765 |     4221 |     5230 |     6030 |     6651 |     7134 |     7524
    [bazaar]    |       50 |      159 |      252 |      351 |      425 |      483 |      506 |      525 |      534

यह पूरी तरह से संतोषजनक नहीं है जिसमें से तीन प्रतिस्पर्धी अभी तक काफी हद तक खुले स्रोत उत्पादों को चुनने के लिए चुना गया है। व्यक्तिगत रूप से मैं गिट का उपयोग करता हूं और मैं दूसरे दो के साथ ठीक हूं। लेकिन जब दूसरों पर एक प्रणाली की सिफारिश करने की बात आती है, तो मैं पूछना चाहूंगा: क्या हम अभी तक एक सुरक्षित रूप से सिफारिश करना शुरू कर सकते हैं?

200 9 के मध्य से टिप्पणियां : सबवर्जन की हाल की ऐतिहासिक लोकप्रियता स्पष्ट रूप से प्रश्नों की संख्या से प्रतिबिंबित होती है, जो कम से कम मर्कुरियल या बाज़ार पर गिट की ओर स्केल की एक छोटी सी टिपिंग का संकेत देती है।

2010 के मध्य से टिप्पणियां : Mercurial संख्याओं में उस विशाल सापेक्ष वृद्धि को देखो। स्पष्ट रूप से केवल दो-डेटा बिंदु एक प्रवृत्ति दिखाने के लिए पर्याप्त नहीं हैं, लेकिन ऐसा लगता है कि गिट और सबवर्जन बड़े पैमाने पर फैले हुए हैं, मर्कुरियल ने बहुत अधिक विकास देखा है, और बाजार अपेक्षाकृत शांत रहा है।

संक्षिप्त टिप्पणी, मध्य -2011 : क्या हम सिर्फ विजेता गिट को बुला सकते हैं? :) नहीं, मैं तर्क स्वीकार करता हूं कि प्रश्नों की संख्या लोकप्रियता के बराबर नहीं है। संख्याएं निश्चित हैं, हालांकि मजबूत हैं।


इन तीन वितरित संस्करण नियंत्रण प्रणालियों के लिए इस साइट पर प्रश्नों की संख्या के आधार पर, यह गिट की तरह लगता है

  1. अधिक लोकप्रिय है, या
  2. अधिक कठिन है (इसलिए अधिक प्रश्नों की आवश्यकता है), या
  3. इसमें अधिक सुविधाएं हैं (इसलिए अधिक प्रश्नों की आवश्यकता है)।
  1. एससीएम लोकप्रियता के बारे में - निम्नलिखित स्टैक ओवरफ्लो प्रश्न देखें: क्या फ्री आरसीएस / एससीएम / वीसीएस सिस्टम के लिए कोई लोकप्रियता / उपयोग आंकड़े उपलब्ध हैं? । यहां हमारे पास प्रश्न हैं जैसे कि विशिष्ट प्रकार की परियोजना के लिए उपयोग करने के लिए अनदेखा फाइलों का कौन सा सेट, जो एससीएम अज्ञेयवादी हैं, लेकिन गिट (और 'गिट' टैग का उपयोग करके) के लिए कहा जाता है, क्योंकि यह वही व्यक्ति है जिसने प्रश्न पूछने के लिए कहा है।

  2. गिट के बारे में अधिक कठिन होना (और इसलिए SO पर अधिक प्रश्न हैं) - निश्चित रूप से गिट में सीखने की वक्र है। यह कुछ (काफी) अद्वितीय अवधारणाओं का भी उपयोग करता है, जैसे स्टेजिंग क्षेत्र (इंडेक्स), या सभी शाखाएं बराबर होती हैं, जो इसकी शक्ति के लिए ज़िम्मेदार होती हैं, लेकिन पहले सही हो सकती है (विशेष रूप से यदि कोई अन्य एससीएम से आता है) । इसके अलावा गिट यूआई पूरी तरह से संगत नहीं है (हालांकि यह बेहतर हो जाता है), क्योंकि इसे विकसित करने के बजाय उगाया गया था; जो इसकी शक्ति के लिए ज़िम्मेदार है, लेकिन उप-उपयोगकर्ता यूजर इंटरफेस का कारण बन सकता है।

  3. गिट के बारे में अधिक सुविधाएं हैं - आपको यह जांचना होगा कि गिट की उन्नत / असामान्य सुविधाओं के बारे में कितने SO प्रश्न हैं। आपको अवगत होना चाहिए कि ओपन सोर्स प्रोजेक्ट एक-दूसरे से विचार उधार लेते हैं, या समान रूप से विकसित की गई समान विशेषताएं हैं: एक उदाहरण को प्रतिबद्धता के लिए इतिहास (खोज) इतिहास द्वारा बग मिल जाएगा जो कि बग (जहां तक ​​मुझे पता है) विकसित किया गया था पहले गिट में, और उसके बाद बाजार में प्लगइन के रूप में कार्यान्वित किया गया, और पहले विस्तार और वर्तमान में Mercurial में कोर कार्यक्षमता। एक और डार्क्स व्यवहार से प्रेरित, प्रतिबद्ध करने के परिवर्तनों के टुकड़े का चयन करने पर इंटरैक्टिव होगा। फिर भी एक और गिट का बंडल विचार होगा, जो मर्कुरियल में इसी तरह की अवधारणा से उधार लिया गया था।

  4. फिर भी एसओ प्रश्न की बड़ी संख्या के स्रोत की एक अन्य संभावना में अच्छे दस्तावेज की कमी हो सकती है ... हालांकि यह आजकल गिट यूज़र के मैनुअल (गिट के साथ वितरित) और गिट कम्युनिटी बुक (गिट होमपेज पर पाया गया) के साथ बेहतर हो जाता है। फिर भी इस लगातार ज्ञापन में कहा गया है कि गिट के सबवर्सन ( एसवीएनबुक के रूप में भी जाना जाता है) के साथ वर्जन कंट्रोल के साथ सबवर्सन की तुलना में खराब दस्तावेज है और मर्क्यूरियल: द डिफिनिटिव गाइड ( एचजी-बुक के रूप में भी जाना जाता है) ... और लोग नहीं पढ़ते कभी-कभी स्टैक ओवरव्लो पर प्रश्न पूछने से पहले दस्तावेज़ीकरण।

यह पूरी तरह से संतोषजनक नहीं है जिसमें से तीन प्रतिस्पर्धी अभी तक काफी हद तक खुले स्रोत उत्पादों को चुनने के लिए चुना गया है। व्यक्तिगत रूप से मैं गिट का उपयोग करता हूं और मैं दूसरे दो के साथ ठीक हूं। लेकिन जब दूसरों पर एक प्रणाली की सिफारिश करने की बात आती है, तो मैं पूछना चाहूंगा: क्या हम अभी तक एक सुरक्षित रूप से सिफारिश करना शुरू कर सकते हैं?

खैर, गिट और मर्कुरियल को लिनक्स कर्नेल डेवलपर्स द्वारा उपयोग के लिए बिटकिपर के लिए मुफ्त लाइसेंस समाप्त करने की प्रतिक्रिया में लगभग उसी समय स्वतंत्र रूप से विकसित किया गया था, इसके बदले में। मर्ज ट्रैकिंग के लिए कोर में समर्थन (तब) की कमी के साथ केंद्रीकृत एससीएम के रूप में प्रश्न से बाहर था; इसने इसे लिनक्स कर्नेल के बड़े पैमाने पर वितरित विकास मॉडल के लिए पूरी तरह से अनुपयुक्त बना दिया। बाज़ार शायद बहुत धीमा था (कम से कम तब), और केंद्रीकृत पक्ष पर थोड़ा सा (मुझे लगता है)।

गिट अधिक शक्तिशाली है (मेरी राय में), मर्कुरियल सरल है (लोगों की राय में) और थोड़ा और पोर्टेबल (पायथन); गिट स्क्रिप्ट योग्य है और यह डेटा मॉडल पर आधारित है जो स्वतंत्र पुनर्मूल्यांकन (उदाहरण के लिए जावा में लिखित जीजीआईटी, गिट) की अनुमति देता है, जबकि मर्कुरियल के पास लिखित एक्सटेंशन के लिए पाइथन बाइंडिंग है, और यह मुख्य रूप से एपीआई पर आधारित है जो अंतर्निहित भंडार प्रारूप में परिवर्तन की अनुमति देता है (revlog - revlog-ng ) ... लेकिन यह सिर्फ मेरी प्रकृति है। वे थोड़ा अलग निकस भरते हैं।

इसके अलावा कोई विकल्प अच्छी बात नहीं माना जाता है? हमारे पास केडीई है और हमारे पास गनोम और एक्सएफसीई (और अन्य विंडो प्रबंधक और डेस्कटॉप वातावरण) हैं; हमारे पास Emacs और Vim (और अन्य प्रोग्रामर के संपादक) हैं; हमारे पास आरपीएम-आधारित (जैसे फेडोरा कोर, मैनड्रिवा, एसयूएसई) और डेब-आधारित (डेबियन, उबंटू) और टीजीजे-आधारित (स्लेकवेयर) और स्रोत-आधारित (जेनेटू) वितरण हैं; हमारे पास KWord, AbiWord और OpenOffice.org है ... और हमारे पास गिट, मर्कुरियल और बाज़ार है।


[नोट: सबवर्सन 1.7 के रिलीज के साथ, नीचे दिए गए मेरे उत्तर में पहला पैराग्राफ पुराना है, क्योंकि सबवर्सन अब बेस फ़ोल्डर में एक ".svn" फ़ोल्डर बनाता है, जो अब दूसरों के समान है।]

तीन ओवर ओवरवर्जन में से किसी एक का लाभ यह है कि यह प्रोजेक्ट के प्रत्येक फ़ोल्डर में ".svn" फ़ोल्डर के बराबर नहीं बनाता है। आमतौर पर बेस फ़ोल्डर में केवल एक (".hg", ".bzr" या ".git") होता है। यदि आप एक केंद्रीकृत भंडार मॉडल का उपयोग कर रहे हैं, भले ही वह अकेले svn पर उनमें से एक का उपयोग करने का एक अच्छा कारण हो सकता है। (इसके अलावा: वास्तव में, मैं अक्सर इस सुविधा के लिए एक svn भंडार का उपयोग करते समय अपने svn क्लाइंट के रूप में svk उपयोग करता हूं (लिनक्स केवल तभी, svk विंडोज़ पर अच्छा नहीं है))।

बेशक, विचलन का एक फायदा यह है कि आपको पूरे प्रोजेक्ट को चेक-आउट करने की आवश्यकता नहीं है यदि आपको केवल इसके उप-फ़ोल्डर की आवश्यकता है।


कैनोनिकल (उबंटू) अपने डिस्ट्रो के लिए सॉफ़्टवेयर पैकेज उपयोग ट्रैक करता है , इसलिए लोकप्रियता को मापने के लिए स्टैक एक्सचेंज इश्यू की गणना पर भरोसा करने की आवश्यकता नहीं है। हालांकि, जैसा कि अन्य ने इंगित किया है, यह केवल उबंटू उपयोगकर्ताओं और कैनोनिकल (उबंटू) का उपयोग करता है और बीजीआर (नमूना पूर्वाग्रह) की सिफारिश करता है। फिर भी ...

            2011    2011    2011           
Package     Aug 3   Sep 29  Dec 9   Change 
------      ------  ------  ------  ------ 
git-core    3647    3402    3236    -11%   
bzr         4975    5286    6070    +22%   
mercurial   3411    3387    3461     +1%   

गिट-कोर पैकेज के लिए वोटों में गिरावट से मुझे लगता है कि मैंने कुछ गलत किया है जैसे grep ed ubuntu लोकप्रियता तालिका से गलत पैकेज नाम संपादित करें। या शायद यह "वोट" गिनती स्थापनाओं से संबंधित है और सॉफ्टवेयर का वास्तविक उपयोग नहीं है।

प्रवृत्ति के लिए यहां कुछ ऐतिहासिक डेटा दिया गया है। मैंने इस तालिका में उबंटू के <vote> आंकड़ों के बजाय <install> उपयोग किया था, लेकिन यह 2011 में शुरू होने वाले बाजार और मर्कुरियल में वृद्धि की वृद्धि दर्शाता है। फिर भी, 2011 में bzr पीछे था, लेकिन 2011 के हालिया आंकड़े बताते हैं कि यह कुल स्थापित उदाहरणों (उबंटू पर) में git पास किया गया।

        June    Aug     Dec     Growth  Oct   Growth
        2010    2011    2011            2013 
----    -----   ----    ----    ------  ----  ------
git      94k    159k    171k      80%   165k   -3.5%
bzr      52k    121k    135k     160%   170k   26.0%
hg       36k     68k     75k     110%    95k   26.7%

डिस्कलाइमर: मैंने 2012 तक उबंटू पर बीजीआर का इस्तेमाल किया जब मैंने उन टीमों पर काम किया जो विशेष रूप से git इस्तेमाल करते थे। Bzr अन्य सभी VCSes के साथ अच्छा खेलता है, जिससे आप लगातार, सहज ज्ञान युक्त bzr कमांड लाइन सिंटैक्स का उपयोग कर सकते हैं। git मेरा स्विच तकनीकी कारणों के बजाय सामाजिक था।


गिटहब में गिट के साथ सोशल कोडिंग की उत्पत्ति के बाद, गिट ने कई अनुयायियों को आकर्षित किया है।


मेरे अनुभव में प्रश्नों की संख्या से निर्णय लेने से गिट की तुलना और मर्कुरियल के मुकाबले उल्लेखनीय रूप से कमी आती है। कारण दो गुना है:

  1. hg update --help बनाम git checkout -h और git --help checkout पर एक नज़र डालें। Mercurial के साथ मुझे शायद ही कभी ऐसे प्रश्न मिलते हैं जिन्हें hg help पर कुछ नज़रों से उत्तर नहीं दिया जाता है

  2. Mercurial विकी की जांच करें - अगर आपको मदद की ज़रूरत है , तो आप इसे वहां पाएंगे , जिसमें कई टिप्स और ट्रिक्स शामिल हैं: http://mercurial-scm.org/wiki/TipsAndTricks


मैं Mercurial का उपयोग और अनुशंसा करते हैं

  • विचलन के बजाय क्योंकि यह वितरित विकास का समर्थन करता है। मैं कई मशीनों पर काम कर सकता हूं और स्थानीय रूप से प्रतिबद्ध हूं। आप सबवर्सन के साथ ऐसा नहीं कर सकते हैं, कम से कम बिना अतिरिक्त रिपॉजिटरीज़ के बिना
  • बाज़ार की बजाय बाजार के विंडोज़ समर्थन ... अच्छी तरह से है।
  • गिट के बजाए क्योंकि यह एक है) सीखने और उपयोग करने में आसान और बी) विंडोज़ समर्थन बहुत बेहतर है


वैसे कारण है कि गिट में इतने सारे उपयोगकर्ता हैं कि लिनक्स कर्नेल इसका उपयोग करता है, इसलिए यदि आप लिनक्स विकास करना चाहते हैं, तो आप गिट का उपयोग करें।

चूंकि इतने सारे लोग गिट के साथ शामिल हैं, इसलिए मैं बड़े उपयोगकर्ता आधार के कारण गिट का उपयोग करने की सलाह दूंगा। वास्तव में, ऊपर दिखाए गए नंबर इस का स्पष्ट संकेत हैं।

कठिनाई के लिए, सभी संस्करण नियंत्रण मुश्किल है, खासकर वितरित प्रकार। पहली नज़र में एसवीएन और सीवीएस बिल्कुल कम नहीं थे (कम से कम मेरे लिए)। यह संस्करण नियंत्रण प्रणाली में उपयोग करने के आवश्यक सीखने की वक्र का हिस्सा है।

संपादित करें: चूंकि आपने एक उपवर्तन संदर्भ जोड़ा है, मुझे लगा कि मैं इसे संबोधित करूंगा। मुझे लगता है कि ज्यादातर लोग svn का उपयोग करेंगे क्योंकि इसमें इसके लिए सुंदर जीयूआई इंटरफेस के सभी प्रकार हैं। आम तौर पर, लोग कुछ डेवलपर्स सहित कमांड लाइन का उपयोग करने से नफरत करते हैं। गिट आमतौर पर विंडोज पर बहुत अच्छी तरह से काम नहीं करता है (या कम से कम निर्बाध रूप से नहीं)। चूंकि कई लोग विंडोज़ पर हैं, इसलिए यह संभावित उपयोगकर्ताओं की संख्या को मारता है।

इसके अलावा, मुझे लगता है कि एसवीएन की अवधारणाओं को समझना थोड़ा आसान होता है क्योंकि svn एक वितरित प्रणाली के बजाय केंद्रीय भंडार का उपयोग करता है। यह समझना आसान है, "यहां कोड का बड़ा पहाड़ है, कृपया अपना कोड यहां जोड़ें," यहां कुछ कोड है, मेरा उससे अलग हो सकता है, उसके द्वारा, लेकिन यदि आप चाहें तो कुछ जोड़ सकते हैं। "

मेरी राय में, एसवीएन में प्रलेखन की एक बेहतर प्रणाली है। गिट के दस्तावेज को ज्ञान के थोड़े उच्च स्तर (कार्यक्रम के लिए, प्रोग्रामर इंटेलिजेंस नहीं) पर लक्षित किया जाता है और सिस्टम का उपयोग करने के बाद यह समझ में आता है, लेकिन जब पहली बार शुरू होता है, तो यह सिर्फ गोबल्डेडी-गूक का गुच्छा जैसा दिखता है।

कुल मिलाकर, मुझे लगता है कि svn हमेशा और अधिक प्रचलित होगा क्योंकि इसकी सामान्य ऑपरेटिंग अवधारणाओं को समझना आसान होता है, उपकरण का उपयोग करना आसान होता है, और इसका विंडोज़ पर अद्भुत समर्थन है।

मुझे अपने अंतिम दो सेंट के साथ समाप्त करने दें और कहें कि मुझे गिट पसंद है क्योंकि मुझे लगता है कि यह किसी भी अन्य सिस्टम की तुलना में कहीं अधिक शक्तिशाली है। एक बार प्रोग्राम को बेहतर समझने के बाद सीखने की अवस्था पर चढ़ना निश्चित रूप से भुगतान करता है।





bazaar