मैं एक तोड़फोड़ करने वाला लड़का हूं, मुझे मर्क्यूरियल या गिट या किसी अन्य डीवीसीएस पर विचार क्यों करना चाहिए या नहीं करना चाहिए?

Question

मैं वितरित संस्करण नियंत्रण प्रणाली (डीवीसीएस) के लाभों को समझने की कोशिश करता हूं।

मैंने तोड़फोड़ की पुन: शिक्षा और मार्टिन फाउलर के इस लेख को बहुत उपयोगी पाया।

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

हम इससे प्रभावित नहीं होते हैं क्योंकि मैं निरंतर एकीकरण का अभ्यास करता हूं और निजी शाखा में अकेले काम करना एक विकल्प नहीं है, जब तक कि हम प्रयोग नहीं कर रहे हैं। हम हर बड़े संस्करण के लिए एक शाखा का उपयोग करते हैं, जिसमें हम ट्रंक से मर्ज किए गए कीड़े को ठीक करते हैं।

मर्क्यूरियल आपको लेफ्टिनेंट रखने की अनुमति देता है

मैं समझता हूं कि यह लिनक्स जैसी बहुत बड़ी परियोजनाओं के लिए उपयोगी हो सकता है, लेकिन मैं छोटी और अत्यधिक सहयोगी टीमों (5 से 7 लोगों) में मूल्य नहीं देखता हूं।

मर्क्यूरियल तेज़ होता है, डिस्क स्थान कम लेता है और पूर्ण स्थानीय प्रतिलिपि तेज़ लॉग और ऑपरेशन को अलग करने की अनुमति देती है।

मुझे इससे कोई सरोकार नहीं है, क्योंकि मैंने एसवीएन के साथ गति या स्थान की समस्याओं पर ध्यान नहीं दिया, यहां तक ​​कि मैं बहुत बड़ी परियोजनाओं के साथ काम कर रहा हूं।

मैं आपके व्यक्तिगत अनुभवों और / या पूर्व SVN geeks से राय मांग रहा हूं। विशेष रूप से परिवर्तन की अवधारणा और आपके द्वारा किए गए समग्र प्रदर्शन को बढ़ावा देने के संबंध में ।

अद्यतन (12 जनवरी) : अब मुझे विश्वास है कि यह एक कोशिश के काबिल है।

अद्यतन (12 वीं जून) : मैं मर्क्युरियल चूमा और मुझे यह पसंद आया। उसका चेरी स्थानीय स्वाद। मैं मर्क्युरियल चूमा बस इसे करने की कोशिश करना। मुझे आशा है कि मेरे एसवीएन सर्वर को इससे कोई आपत्ति नहीं है। यह बहुत गलत लगा। यह सही लगा। इसका मतलब यह नहीं है कि मैं आज रात प्यार में हूँ ।

अंतिम अद्यतन (29 जुलाई) : मुझे एरिक सिंक की अगली पुस्तक की समीक्षा करने का सौभाग्य मिला, जिसका उदाहरण संस्करण नियंत्रण है । वह मुझे समझाने के लिए समाप्त हो गया। मैं मर्क्यूरियल के लिए जाऊंगा।

Comments

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

— बेरिन लोरिट्श 14

प्रश्न के लिए +1। आजकल यह कार्गो पंथ बन गया है जिसे वितरित किया जाना बेहतर, तेज, सरल, अधिक प्राकृतिक और परेशानी से मुक्त और केंद्रीकृत की तुलना में 90% शिनियर है। सिवाय इसके कि यह जरूरी नहीं है। वे अलग-अलग उपकरण हैं, और प्रत्येक को कुछ संदर्भों में और अन्य संदर्भों में नुकसान हो सकता है।

— जूनस पुलका

@ शार्पी: दोनों का इस्तेमाल किया है svn, gitऔर hgवर्षों के लिए, मैं उनके पेशेवरों और विपक्ष के बारे में अच्छी तरह से जानता हूं। हालांकि gitनिश्चित रूप से इनमें से सबसे शक्तिशाली है, यह स्वीकार करना महत्वपूर्ण है कि अधिक शक्तिशाली स्वचालित रूप से बेहतर नहीं है । Emacs निश्चित रूप से वेब ब्राउज़र में चल रहे किसी भी जावास्क्रिप्ट टेक्स्ट एडिटर की तुलना में अधिक शक्तिशाली है, लेकिन, अजीब बात है, मैं अभी एक जावास्क्रिप्ट ब्राउज़र टेक्स्ट एडिटर में यह टिप्पणी लिख रहा हूं! सादगी , यहां तक ​​कि मूर्खता, कई संदर्भों में मूल्य है। केंद्रीकृत svnऔर git-svnस्थानीय रूप से कुछ का उपयोग करना दोनों दुनिया के सर्वश्रेष्ठ प्रदान करता है।

— जूनस पुलका

@ शार्टपी: यह आपके लिए अच्छा है कि आप इसे पसंद करते हैं। लेकिन एक आदमी का समर्थक दूसरे आदमी का है। कुछ लोग एकल कैनोनिकल ट्रंक के साथ एक एकल केंद्रीकृत भंडार की स्पष्टता को अविश्वसनीय रूप से मूल्यवान मानते हैं। यहां एक प्रस्तुति दी गई है कि कैसे Google अपने सभी प्रोजेक्ट्स के स्रोत कोड को 2000 से अधिक एकल कोड ट्रंक में सैकड़ों लाखों कोड लाइनों के साथ रखता है , जिसमें 5000 से अधिक डेवलपर्स समान रिपॉजिटरी का उपयोग करते हैं। यदि आप इसके बजाय हर किसी की मेज पर 5000 सर्वर और 2000 परियोजनाओं के इतिहास पसंद करेंगे? -)

— Joonas Pulakka

-1 कैटी पेरी संदर्भ के लिए। ;)

— अमादियेरे

Answer 1

नोट: वर्तमान प्रश्न के उत्तर के लिए "EDIT" देखें

---

सबसे पहले, जोएल स्पोल्स्की द्वारा तोड़फोड़ फिर से शिक्षा पढ़ें । मुझे लगता है कि आपके अधिकांश सवालों का जवाब वहां दिया जाएगा।

एक और सिफारिश, लिनस टॉर्वाल्ड्स की चर्चा Git पर: http://www.youtube.com/watch?v=4XpnKHJok8 । यह अन्य भी आपके अधिकांश प्रश्नों का उत्तर दे सकता है, और यह काफी मनोरंजक है।

BTW, कुछ मुझे काफी मज़ेदार लगता है: यहां तक ​​कि ब्रायन फिट्ज़पैट्रिक और बेन कॉलिन्स-सूसमैन, दो तोड़फोड़ के मूल रचनाकारों ने एक गूगल टॉक में कहा कि "इस बारे में खेद है" कि तोड़फोड़ का जिक्र मर्क्यूरियल (और सामान्य रूप से डीवीसीएस) से किया जा रहा है।

अब, IMO और सामान्य रूप से, टीम की गतिशीलता किसी भी DVCS के साथ स्वाभाविक रूप से विकसित होती है, और एक उत्कृष्ट लाभ यह है कि आप ऑफ़लाइन कर सकते हैं क्योंकि यह निम्नलिखित बातों का तात्पर्य करता है:

• आप एक सर्वर और एक कनेक्शन पर निर्भर नहीं करते हैं, जिसका अर्थ है तेज समय।
• उन जगहों पर गुलाम नहीं होना चाहिए जहां आप इंटरनेट एक्सेस (या वीपीएन) प्राप्त कर सकते हैं, बस करने में सक्षम होने के लिए।
• हर किसी के पास हर चीज (फाइल, इतिहास) का बैकअप होता है, न कि सर्वर का। मतलब कोई भी सर्वर बन सकता है ।
• यदि आप दूसरों के कोड को गड़बड़ाने के बिना ज़रूरत है तो आप अनिवार्य रूप से कर सकते हैं । कमिट स्थानीय हैं। आप एक दूसरे के पैर की उंगलियों पर कदम नहीं रखते। आप केवल कमिट करके अन्य बिल्ड या वातावरण को नहीं तोड़ते हैं।
• "प्रतिबद्ध पहुंच" के बिना लोग प्रतिबद्ध हो सकते हैं (क्योंकि डीवीसीएस में आने से कोड को अपलोड करने का मतलब नहीं है), योगदान के लिए बाधा कम करके, आप उनके बदलावों को खींचने का फैसला कर सकते हैं या एक इंटीग्रेटर के रूप में नहीं।
• यह डीवीसी के बाद से प्राकृतिक संचार को सुदृढ़ कर सकता है। यह आवश्यक है ... तोड़फोड़ में आपके पास इसके बजाय प्रतिबद्ध दौड़ हैं, जो संचार को बाध्य करते हैं, लेकिन आपके काम में बाधा डालते हैं।
• योगदानकर्ता अपनी मर्जिंग को संभाल सकते हैं और अंत में इंटीग्रेटर्स के लिए कम काम कर सकते हैं।
• योगदानकर्ताओं की दूसरों को प्रभावित किए बिना अपनी शाखाएं हो सकती हैं '(लेकिन यदि आवश्यक हो तो उन्हें साझा करने में सक्षम)।

अपने अंकों के बारे में:

• DVCSland में विलय नरक मौजूद नहीं है; को संभालने की जरूरत नहीं है। अगले अंक देखें ।
• डीवीसीएस में, हर कोई एक "शाखा" का प्रतिनिधित्व करता है, जिसका अर्थ है कि विलय हैं हर परिवर्तन को खींच लिया जाता है। नामित शाखाएं एक और चीज हैं।
• आप चाहें तो निरंतर एकीकरण का उपयोग कर सकते हैं। आईएमएचओ आवश्यक नहीं है, फिर भी जटिलता क्यों जोड़ें ?, बस अपने परीक्षण को अपनी संस्कृति / नीति के हिस्से के रूप में रखें।
• कुछ चीजों में मर्क्यूरियल तेज होता है, अन्य चीजों में गिट तेज होता है। वास्तव में DVCSs के लिए सामान्य रूप से नहीं, लेकिन उनके विशेष कार्यान्वयन AFAIK तक।
• हर किसी के पास हमेशा पूरा प्रोजेक्ट होगा, केवल आप ही नहीं। वितरित की गई चीज़ों का यह करना है कि आप स्थानीय रूप से / अपडेट कर सकते हैं, अपने कंप्यूटर के बाहर साझा / लेना-देना पुश / पुलिंग कहलाता है।
• फिर से, तोड़फोड़ पुनः शिक्षा पढ़ें। DVCS आसान और अधिक प्राकृतिक हैं, लेकिन वे अलग-अलग हैं, यह सोचने की कोशिश न करें कि सभी संस्करणों के cvs / svn === आधार।

मैं DVCS के माइग्रेशन का प्रचार करने में मदद करने के लिए जूमला परियोजना में कुछ प्रलेखन का योगदान दे रहा था, और यहाँ मैंने केंद्रीकृत बनाम वितरित चित्रण के लिए कुछ आरेख बनाए।

केन्द्रीकृत

सामान्य व्यवहार में वितरित

पूरा बांट दिया

आप चित्र में देखते हैं कि अभी भी एक "केंद्रीकृत भंडार" है, और यह केंद्रीकृत संस्करण प्रशंसकों के पसंदीदा तर्कों में से एक है: "आप अभी भी केंद्रीकृत हो रहे हैं", और नहीं, आप नहीं हैं, क्योंकि "केंद्रीकृत" भंडार सिर्फ भंडार है सभी सहमत हैं (उदाहरण के लिए एक आधिकारिक गीथूब रेपो), लेकिन यह किसी भी समय आपकी आवश्यकता के अनुसार बदल सकता है।

अब, यह ओपन-सोर्स प्रोजेक्ट्स के लिए विशिष्ट वर्कफ़्लो है (उदाहरण के लिए DVCS का उपयोग करके बड़े पैमाने पर सहयोग वाला प्रोजेक्ट):

Bitbucket.org कुछ हद तक मर्क्यूरियल के बराबर है, यह जान लें कि उनके पास असीमित स्थान के साथ असीमित निजी रिपॉजिटरी हैं, यदि आपकी टीम पांच से छोटी है तो आप इसे मुफ्त में उपयोग कर सकते हैं।

सबसे अच्छा तरीका है कि आप अपने आप को एक डीवीसीएस का उपयोग करने के लिए मना सकते हैं, एक डीवीसीएस की कोशिश कर रहे हैं, हर अनुभवी डीवीसीएस डेवलपर जिसने svn / cv का उपयोग किया है, आपको बताएगा कि यह इसके लायक है और वे नहीं जानते कि वे इसके बिना अपना सारा समय कैसे बचाते हैं।

---

संपादित करें : आपके दूसरे संपादन का उत्तर देने के लिए मैं सिर्फ यह दोहरा सकता हूं कि DVCS के साथ आपके पास एक अलग वर्कफ़्लो है, मैं आपको सलाह दूंगा कि सर्वोत्तम प्रथाओं के कारण इसे नहीं आज़माने के कारणों की तलाश करें , ऐसा लगता है जब लोग तर्क देते हैं कि OOP नहीं है आवश्यक है क्योंकि वे जटिल डिजाइन पैटर्न के साथ प्राप्त कर सकते हैं जो वे हमेशा प्रतिमान XYZ के साथ करते हैं; आप किसी भी तरह से लाभ उठा सकते हैं।

इसे आज़माएँ, आप देखेंगे कि "प्राइवेट ब्रांच" में काम करना वास्तव में एक बेहतर विकल्प है। एक कारण मैं इस बारे में बता सकता हूं कि अंतिम सत्य क्यों है क्योंकि आप प्रतिबद्ध होने के डर को खो देते हैं , जिससे आप किसी भी समय आपको फिट होने और अधिक प्राकृतिक तरीके से काम करने की अनुमति दे सकते हैं।

"विलय नरक" के बारे में, आप कहते हैं "जब तक हम प्रयोग नहीं कर रहे हैं", मैं कहता हूं "भले ही आप प्रयोग कर रहे हों + एक ही समय में v2.0 पुर्नोत्थान में काम कर रहे हैं "। जैसा कि मैं पहले कह रहा था, नरक का विलय नहीं होता, क्योंकि:

• हर बार जब आप प्रतिबद्ध होते हैं तो आप एक अनाम शाखा उत्पन्न करते हैं, और हर बार आपके परिवर्तन अन्य व्यक्तियों के परिवर्तनों से मिलते हैं, एक प्राकृतिक मर्ज होता है।
• क्योंकि DVCS प्रत्येक कमिट के लिए अधिक मेटाडेटा एकत्र करते हैं, विलय के दौरान कम संघर्ष होते हैं ... इसलिए आप इसे "बुद्धिमान मर्ज" भी कह सकते हैं।
• जब आप मर्ज संघर्ष में टकराते हैं, तो यह वह है जो आप उपयोग कर सकते हैं:

इसके अलावा, परियोजना का आकार मायने नहीं रखता है, जब मैं तोड़फोड़ से बदल गया था मैं वास्तव में पहले से ही लाभ देख रहा था जबकि अकेले काम कर रहा था, सब कुछ बस सही लगा। Changesets (वास्तव में नहीं एक संशोधन है, लेकिन आप एक प्रतिबद्ध शामिल विशिष्ट फ़ाइलों के लिए परिवर्तन, codebase के राज्य से अलग का एक विशिष्ट सेट), तो आप कल्पना कर आप फ़ाइलों की एक विशिष्ट समूह के लिए क्या कर रहे थे द्वारा वास्तव में क्या मतलब है चलो पूरे कोडबेस नहीं।

परिवर्तन कैसे काम करता है और प्रदर्शन को बढ़ावा देता है। मैं इसे एक उदाहरण से स्पष्ट करना चाहूंगा जो मैं देना चाहता हूं: svn से mootools प्रोजेक्ट स्विच उनके github नेटवर्क ग्राफ में सचित्र ।

इससे पहले

उपरांत

आप जो देख रहे हैं, डेवलपर्स को शुरू करते समय अपने स्वयं के काम पर ध्यान केंद्रित करने में सक्षम होना चाहिए, दूसरों के कोड को तोड़ने के डर के बिना, वे धक्का देने / खींचने के बाद दूसरों के कोड को तोड़ने के बारे में चिंता करते हैं (डीवीसीएस: पहले प्रतिबद्ध, फिर धक्का / खींच, फिर अपडेट करें ) लेकिन चूंकि विलय यहां अधिक होशियार है, वे अक्सर ऐसा नहीं करते हैं ... यहां तक ​​कि जब कोई मर्ज संघर्ष होता है (जो कि दुर्लभ है), तो आप केवल 5 मिनट या उससे कम समय बिताते हैं।

मेरी आपसे सिफारिश है कि आप किसी ऐसे व्यक्ति की तलाश करें, जो यह जानता हो कि किस तरह से मर्क्यूरियल / गिट का उपयोग करना है और उसे अपने हाथों से समझाने के लिए उसे बताना है। कमांड लाइन में कुछ दोस्तों के साथ लगभग आधे घंटे का समय बिताते हुए, हमारे डेस्कटॉप और बिटकॉइन खातों के साथ मर्क्यूरियल का उपयोग करते हुए उन्हें मर्ज करने का तरीका दिखाया गया, यहां तक ​​कि उनके लिए संघर्षों को गढ़ते हुए यह देखने के लिए कि कैसे एक हास्यास्पद समय में ठीक करने के लिए, मैं दिखाने में सक्षम था उन्हें एक DVCS की असली शक्ति।

अंत में, मैं आपको git + github के बजाय mercurial + bitbucket का उपयोग करने की सलाह दूंगा यदि आप windows लोगों के साथ काम करते हैं। मर्क्यूरियल भी एक सरल और अधिक सरल है, लेकिन अधिक जटिल रिपॉजिटरी प्रबंधन (जैसे गिट रीबेस ) के लिए git अधिक शक्तिशाली है ।

कुछ अतिरिक्त अनुशंसित रीडिंग:

• डिस्ट्रीब्यूटेड रिविजन कंट्रोल सिस्टम: गिट बनाम मर्क्यूरियल बनाम एसवीएन
• Git बनाम Mercurial: कृपया आराम करें
• वितरित संस्करण नियंत्रण और गिट [भाग 1] और वितरित संस्करण नियंत्रण और गिट [भाग 2]
• Git / Mercurial बनाम तोड़फोड़: लड़ाई!
• डीवीसीएस बनाम तोड़फोड़ स्मैकडाउन, राउंड 3
• मुझे मर्क्यूरियल लाइक गैट से ज्यादा ( भाग 1 , भाग 2 )
• Git के साथ योगदान: GIT VCS के साथ ओपन सोर्स सहयोग के घर्षण को कम करना
• "डीवीसी ने आपके लिए अब तक कैसे काम किया है?" - जुमला पर पोस्ट! फ्रेमवर्क डेवलपमेंट मेलिंग सूची जूमला के लिए मर्क्यूरियल और गिट के प्रायोगिक अपनाने के बाद प्रतिक्रिया के लिए पूछ रही है! प्लेटफार्म परियोजना
• DVCS ब्रांचिंग (मर्क्यूरियल के साथ) - एक विस्तृत और उदाहरण-उन्मुख परिचय जो ब्रांचिंग एक डीवीसीएस में दिखता है, जो संभवतः इन प्रणालियों में सबसे महत्वपूर्ण विशेषता है

Comments

महान जवाब, लेकिन ओपी के रूप में एक ही नाव में हम में से उन लोगों के लिए सिर्फ एक प्रश्न: क्या आप बता सकते हैं कि विलय नरक कैसे मौजूद नहीं है? जब एक कांटा तारीख से बाहर हो गया है तो क्या एक इंटीग्रेटर या एक योगदानकर्ता को उन्हीं कार्यों से गुजरने की जरूरत नहीं है?

— निकोल

अच्छा उत्तर। बस एक ओर ध्यान दें: जबकि स्पॉलस्की में कुछ अच्छे बिंदु हो सकते हैं, ध्यान रखें कि वह उन बिंदुओं को बेचने वाली सामग्री के रूप में उपयोग करके उत्पाद बेचने की कोशिश कर रहा है, जो उन्हें थोड़ा पक्षपाती बनाता है।

— मार्टिन विकमन 16

मैंने उस री-एजुकेशन पेज को पढ़ा, और इसे कई कारणों से प्रासंगिक नहीं पाया। मैं इस विषय पर अपने व्यक्तिगत विचार के साथ अपने प्रश्न को संपादित करूँगा।

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

— ग्रेफेड

@Prere, DVCS व्यक्तिगत प्रोग्रामर से सॉफ़्टवेयर परिवर्तनों को मर्ज करने का ध्यान रखता है , लेकिन वास्तव में सॉफ़्टवेयर को संकलित करने या मौजूदा इकाई परीक्षणों को पारित करने पर नहीं। जब भी स्रोत बदले, तब भी आपको ऐसा करने के लिए अन्य सॉफ़्टवेयर की आवश्यकता होगी, और हमारे पास इन दिनों सबसे अच्छा दांव एक

Answer 2

आप जो कह रहे हैं वह अन्य बातों में है कि यदि आप अनिवार्य रूप से एकल शाखा पर रहते हैं, तो आपको वितरित संस्करण नियंत्रण की आवश्यकता नहीं है।

यह सच है, लेकिन क्या यह आपके काम करने के तरीके के लिए एक अनावश्यक रूप से मजबूत प्रतिबंध नहीं है, और एक जो कई टाइमज़ोन में कई स्थानों पर अच्छी तरह से पैमाने पर नहीं है? केंद्रीय तोड़फोड़ सर्वर कहाँ स्थित होना चाहिए, और यदि किसी कारण से सर्वर डाउन हो तो क्या सभी को घर जाना चाहिए?

DVCSes तोड़फोड़ करने के लिए हैं, Bittorrent क्या ftp करने के लिए है

(तकनीकी रूप से, कानूनी रूप से नहीं)। शायद अगर आप सोचते हैं कि आप समझ सकते हैं कि यह इतनी बड़ी छलांग क्यों है?

मेरे लिए, हमारे स्विच करने के लिए स्विच, तुरंत में परिणाम

• हमारा बैकअप करना आसान है (बस "रिमोट अपडेट अपडेट करें" और आपका काम हो गया)
• केंद्रीय भंडार तक पहुँच के बिना काम करते समय छोटे कदमों को आसान बनाना। जब आप केंद्रीय रिपॉजिटरी की मेजबानी करने वाले नेटवर्क पर वापस आते हैं तो आप बस काम करते हैं, और सिंक्रनाइज़ करते हैं।
• तेज़ हडसन बनाता है। अद्यतन करने की तुलना में गिट पुल का उपयोग करने के लिए बहुत तेजी से।

तो, विचार करें कि क्यों बिटपोरेंट ftp से बेहतर है, और अपनी स्थिति पर पुनर्विचार करें :)

---

नोट: यह उल्लेख किया गया है कि ऐसे उपयोग-मामले हैं जहां ftp तेज और बिटोरेंट से अधिक है। यह उसी तरह से सच है जिस तरह से आपके पसंदीदा संपादक द्वारा बैकअप की गई फ़ाइल एक संस्करण नियंत्रण प्रणाली की तुलना में उपयोग करने के लिए तेज है।

Comments

मैं लगभग एक वास्तविक परियोजना के साथ कोशिश करने का फैसला कर रहा हूँ।

अच्छा विचार। "मैं वास्तव में यह पसंद है" की मानसिकता के साथ इसमें जाने के लिए याद रखें! इसके बजाय "मैं यह नहीं करना चाहता!"। सीखने के लिए बहुत कुछ है। यदि आप git चुनते हैं, तो github के पास बहुत सारी ऑनलाइन मदद है। यदि आप hg चुनते हैं, तो Joel ने कुछ अच्छी ऑनलाइन सामग्री लिखी है। यदि आप bzr चुनते हैं, तो Canonical सबसे अधिक संभावना है कि ऑनलाइन सामग्री बहुत अच्छी है। अन्य?

हम्म जो मानता है कि आपको लगता है कि बिटफ़ोरेंट एफ़टीपी से बेहतर है ...

— मर्फ़

@ मर्फ़, मैं करता हूं, और इसलिए बर्फ़ीला तूफ़ान (जो मुझे लगता है कि हम इस बात पर सहमत हो सकते हैं कि ऑनलाइन ऑनलाइन सिंक्रनाइज़ेशन से कैसे निपटें?)। wowwiki.com/Blizzard_Downloader

@ मर्फ़, आप सर्वर पर एक टोरेंट सर्वर और क्लाइंट पर एक टोरेंट क्लाइंट शुरू करते हैं। मुश्किल नहीं। यह आपको तुरंत खरीदना चाहिए कि केवल उन फ़ाइलों को बदल दिया गया है जिन्हें अद्यतन करने की आवश्यकता है। इसके अलावा, क्या आपने सोचा है कि ftp के बजाय rsync आपको वृद्धिशील अपडेट के लिए क्या खरीद सकता है?

Answer 3

वितरित संस्करण नियंत्रण प्रणालियों की हत्यारा सुविधा वितरित भाग है। आप रिपॉजिटरी से "वर्किंग कॉपी" चेकआउट नहीं करते हैं, आप रिपॉजिटरी की पूरी कॉपी क्लोन करते हैं। यह बहुत बड़ा है, क्योंकि यह शक्तिशाली लाभ प्रदान करता है:

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

• स्थानीय रिपॉजिटरी होने का असली कारण हत्यारा है कि मास्टर रिपॉजिटरी में धकेलने से पहले आपके प्रतिबद्ध इतिहास पर आपका कुल नियंत्रण होता है ।

कभी एक बग तय किया और कुछ इस तरह से समाप्त किया:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

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

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

r321 Fixed annoying bug.

यह किस तरह से होना चाहिए।

इतिहास को फिर से लिखने की क्षमता और भी अधिक शक्तिशाली है जब ब्रांचिंग मॉडल के साथ जोड़ा जाता है। एक डेवलपर वह काम कर सकता है जो पूरी तरह से एक शाखा के भीतर अलग-थलग है और फिर जब उस शाखा को ट्रंक में लाने का समय है तो आपके पास सभी प्रकार के दिलचस्प विकल्प हैं:

• एक सादे वेनिला मर्ज करें । मौसा और सभी में सब कुछ लाता है।

• एक रिबास करो । आपको शाखा इतिहास के माध्यम से छाँटने की अनुमति देता है, कमिट्स के क्रम को फिर से व्यवस्थित करता है, कमिट्स को बाहर फेंकता है, साथ में कमिट करता है, कमिट मैसेज को फिर से लिखता है --- यहां तक ​​कि कमिट्स को एडिट या नया भी जोड़ता है! एक वितरित संस्करण नियंत्रण प्रणाली में कोड समीक्षा के लिए गहरा समर्थन है।

एक बार जब मुझे पता चला कि कैसे स्थानीय रिपॉजिटरी ने मुझे अपने साथी प्रोग्रामरों की पवित्रता और अपने भविष्य के लिए अपने इतिहास को संपादित करने की अनुमति दी, तो मैंने अच्छे के लिए एसवीएन को लटका दिया। मेरा सबवर्सन क्लाइंट अब है git svn।

डेवलपर्स और प्रबंधकों को अनुमति देना बेहतर परियोजना इतिहास में प्रतिबद्ध इतिहास परिणामों पर संपादकीय नियंत्रण का अभ्यास करना और स्वच्छ इतिहास के साथ काम करना वास्तव में एक प्रोग्रामर के रूप में मेरी उत्पादकता में मदद करता है। अगर यह सब "पुनर्लेखन इतिहास" के बारे में बात करता है, तो आपको डराता है, चिंता न करें क्योंकि यह केंद्रीय, सार्वजनिक या मास्टर रिपॉजिटरी के लिए है। इतिहास (और!) को उस बिंदु तक फिर से लिखा जा सकता है जहां कोई उसे एक भंडार में लाता है जिसे अन्य लोग खींच रहे हैं। उस बिंदु पर इतिहास को एक पत्थर की गोली पर उकेरा हुआ माना जाना चाहिए।

Comments

इतिहास को फिर से लिखना: क्या यह सिर्फ एक बात है? या यह मर्क्यूरियल में भी आसान है? (यदि यह है, तो मुझे वास्तव में इसे करने की आवश्यकता है।)

— पॉल डी। वेट

ऐसा करते समय लिनक्स कर्नेल अनुशासन के बारे में पता होना चाहिए - अर्थात्, कभी भी इतिहास को फिर से प्रकाशित (या फिर से लिखना) न करें जो आपने सार्वजनिक रूप से प्रकाशित किया है। यदि आपके पास ऐसी शाखाएँ हैं जो अल्पकालिक उपयोग के लिए सार्वजनिक हैं (शाखाओं में विलय करने के लिए जो अक्सर लाइनक्स-नेक्स्ट की तरह फेंक दी जाती हैं, या किसी की समीक्षा करने के लिए और फिर उनकी स्थानीय प्रतियां फेंक देते हैं) तो आप उन शाखाओं को रिजेक्ट कर सकते हैं - लेकिन आपकी अन्य उपयोगकर्ताओं को स्पष्ट होना चाहिए कि उस शाखा के लिए कन्वेंशन यह है कि इसे फिर से शुरू किया जा सकता है और किसी अन्य लोगों की दीर्घकालिक शाखाओं में विलय नहीं किया जाना चाहिए।

— केन ब्लूम

पूर्ण आंतरिक नेटवर्क एक्सेस के बिना आपके पास बहुत अच्छी तरह से इंटरनेट का उपयोग हो सकता है। यात्रा करते समय अक्सर मेरे साथ ऐसा होता है।

इंटरनेट एक्सेस की आवश्यकता नहीं है, यह बहुत बड़ी बात है, क्योंकि डीवीसीएस की गति यही है। जैसे ही आपको एक नेटवर्क पर पैकेट भेजना होता है, आप परिमाण के क्रम से प्रक्रिया को धीमा कर रहे होते हैं या इस बात की परवाह किए बिना कि आपका कनेक्शन कितना अच्छा है।

— एडम लाससेक

@ पाओल, मेरी समझ यह है कि मर्क्यूरियल में यह किया जा सकता है, लेकिन यह आधार कार्यक्षमता या दर्शन नहीं है।

— बेंजोल

Answer 4

dukofgamings का उत्तर शायद उतना ही अच्छा है जितना इसे मिल सकता है, लेकिन मैं इसे अलग दिशा से देखना चाहता हूं।

चलिए हम मान लेते हैं कि आप जो कहते हैं वह बिलकुल सच है, और यह कि अच्छे व्यवहारों को लागू करने से आप उन समस्याओं से बच सकते हैं जिन्हें DVCS को ठीक करने के लिए डिज़ाइन किया गया था। क्या इसका मतलब यह है कि एक DVCS आपको कोई लाभ नहीं देगा? लोग बदबू सर्वोत्तम प्रक्रियाओं का पालन पर। लोग गड़बड़ करने जा रहे हैं । तो आप उन सॉफ़्टवेयर से क्यों बचेंगे जो समस्याओं के एक सेट को ठीक करने के लिए डिज़ाइन किए गए हैं, इसके बजाय लोगों पर भरोसा करने के लिए कुछ ऐसा करने के लिए चुनें जो आप पहले से अनुमान लगा सकते हैं कि वे क्या नहीं करने जा रहे हैं?

Comments

वास्तव में मैं इस तर्क को DCVS के खिलाफ प्रस्तावित करूंगा। मेरी कंपनी ने हाल ही में CVS से Mercurial पर स्विच किया। सीवीएस होने पर लोग मर्ज के दौरान अन्य लोगों के बदलावों को मिटा रहे हैं।

— जूजोस कंटोवैनिस

@JuozasKontvainis: मैं बहुत अच्छी तरह से मर्क्यूरियल नहीं जानता, लेकिन इसके अलावा आप उन पुशों को भी अस्वीकार कर सकते हैं जिनमें मर्ज शामिल हैं, जिनमें माता-पिता के रूप में HEAD नहीं है, जो उपयोगकर्ताओं को उन परिवर्तनों को धकेलने से रोकता है जिनमें मास्टर शामिल नहीं हैं। मुझे यकीन है कि भाड़े में कुछ ऐसा ही है।

— n

@ naught101: वास्तव में, मेरी कंपनी की वह सेटिंग सक्षम है। क्या होता है कि प्रोग्रामर स्थानीय स्तर पर अपने बदलाव करता है, फिर धक्का देने की कोशिश करता है। उसे सर्वर से एक प्रतिक्रिया मिलती है जिसे धक्का देने से पहले उसे विलय की आवश्यकता होती है। वह सर्वर से अपडेट प्राप्त करता है और मर्ज करने का प्रयास करता है। इस बिंदु पर मुझे ठीक से पता नहीं है कि उन लोगों ने मर्ज कमिट कैसे किया, लेकिन कई मौकों पर मर्ज कमिटमेंट ने मूल रूप से सर्वर से मिले परिवर्तनों को मिटा दिया।

— जुओजस कोंवेंटविस

ऐसा लगता है कि लोगों ने परिवर्तनों को खींच लिया, फिर विलय (जो संभव है) होने पर सर्वर से प्राप्त परिवर्तनों को वास्तव में हटा दिया। बेशक, सर्वर से बदलाव अभी भी है, इसलिए आप रिपॉजिटरी को उस स्थिति में रीसेट कर सकते हैं जो उनके परिवर्तनों से पहले थी।

— फिलोसोडैड

वास्तव में, यह इस तरह से लगता है: randyfay.com/content/avoiding-git-disasters-gory-story अच्छा, गैर-महत्वपूर्ण लेख के बारे में क्या एक गलत रेपो के साथ गलत हो सकता है यदि आप नहीं जानते कि आप क्या कर रहे हैं।

— gbjbaanb

Answer 5

हां, यह दुख होता है जब आपको तोड़फोड़ में बड़े कमियों का विलय करना पड़ता है। लेकिन यह भी एक महान सीखने का अनुभव है, जिससे आप विलय संघर्षों से बचने के लिए हर संभव प्रयास कर सकते हैं। दूसरे शब्दों में, आप अक्सर जांचना सीखते हैं । किसी भी सह-स्थित परियोजना के लिए प्रारंभिक एकीकरण एक बहुत अच्छी बात है। जब तक हर कोई ऐसा कर रहा है, तब तक तोड़फोड़ का उपयोग करना एक समस्या नहीं होनी चाहिए।

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

इसलिए, सह-स्थित, सीआई-उपयोग करने वाली टीम के लिए, मुझे वास्तव में यह नहीं लगता कि आप वितरित प्रणाली का उपयोग करते हैं या नहीं। यह स्वाद और अनुभव के मामले में उबलता है।

Comments

गिट दुनिया भर में वितरित काम के लिए डिज़ाइन किया गया था और लोगों को अपनी परियोजनाओं पर काम करने और खुद के कांटे बनाने के लिए प्रोत्साहित करता है। यह विशेष रूप से "छोटी और अत्यधिक सहयोगी टीमों" में निरंतर एकीकरण के लिए डिज़ाइन नहीं किया गया था जो कि ओपी पूछ रहा है।

— मार्टिन विकमन

क्या लगता है, आपको हल करने के लिए छोटे / आसान संघर्ष मिलते हैं। लेकिन अगर दो पीपीएल कोड के समान भागों को बदल रहे हैं, तो आपको अपनी टीम में एक योजना की समस्या है, और जिसे किसी भी वीसीएस द्वारा हल नहीं किया जा सकता है। वितरित या नहीं।

— मार्टिन विकमैन

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

— मार्टिन विकमैन

@MartinWickman - मर्क्यूरियल को कमिटिंग, ब्रांचिंग और तेजी से और सस्ते विलय करने के लिए डिज़ाइन किया गया था। यह निरंतर एकीकरण के लिए एकदम सही लगता है। व्यक्तिगत रूप से, मुझे लगता है कि ऐलिस के लिए अपने परिवर्तनों को शाखा देने की क्षमता होना और सुझाव देना कि बॉब उन्हें खींचे और समस्याओं के लिए जाँच करने के लिए उस शाखा में अपने परिवर्तनों को मर्ज करें - सभी केंद्रीय सर्वर को छूने या कहीं भी परिवर्तन को धक्का दिए बिना - एक शानदार तरीका लगता है काम करने के लिए छोटी और अत्यधिक सहयोगी टीमों के लिए।

— फिलोसोडैड

मेरी $ 0.02। मैंने विभिन्न परियोजनाओं के लिए अब तोड़फोड़, मरकरी और गिट का इस्तेमाल किया है। निरंतर एकीकरण करने वाले बहुत कसकर एकीकृत समूह के लिए तोड़फोड़ वास्तव में सबसे अच्छा विकल्प लगता है। मर्क्यूरियल उन समूहों के लिए एक बेहतर फिट है जो हर दिन एक ही बार बहुत अधिक कोड परिवर्तन के साथ एक दिन का निर्माण कर सकते हैं (जो कि SVN में मर्ज की समस्या पैदा करेगा)। Git उन लोगों के लिए जाने का तरीका है, जिनके पास ऐसी टीमें हैं जो एक निर्माण करने के लिए कोड को एक साथ धकेलने के बिना दिन / सप्ताह जा सकते हैं।

— ब्रायन नॉबलुच

Answer 6

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

मेरा मानना ​​है कि जब मैंने इसका इस्तेमाल शुरू किया था, उस समय यह सबसे अच्छा विकल्प था। लेकिन अन्य उपकरण समय के साथ आते हैं, और अब मैं अपने खुद के खाली समय की परियोजनाओं के लिए भी पसंद करता हूं।

और तोड़फोड़ में कुछ कमियां हैं। उदाहरण के लिए, यदि आप डिस्क पर एक निर्देशिका का नाम बदलते हैं, तो इसका नाम रिपॉजिटरी में नहीं दिया जाता है। फ़ाइल ले जाने का समर्थन नहीं किया जाता है, किसी फ़ाइल को कॉपी / डिलीट ऑपरेशन में स्थानांतरित करना, विलय करना परिवर्तन करना जब फ़ाइलों को स्थानांतरित किया गया है / नाम बदला गया है। और मर्ज ट्रैकिंग वास्तव में सिस्टम में नहीं बनती है, बल्कि वर्कअराउंड के रूप में कार्यान्वित की जाती है।

Git इन समस्याओं को हल करता है (यदि किसी फ़ाइल को ले जाया गया है तो स्वचालित रूप से पता लगाने सहित, आपको यह बताने की आवश्यकता नहीं है कि यह एक तथ्य है)।

दूसरी ओर गिट आपको अलग-अलग निर्देशिका स्तरों पर शाखा करने की अनुमति नहीं देता है जैसे कि तोड़फोड़ करता है।

तो मेरा जवाब है, आपको विकल्पों की जांच करनी चाहिए, देखें कि क्या यह आपकी आवश्यकताओं से बेहतर है जो आप परिचित हैं, और फिर तय करें।

Comments

बहुत सही है, विकल्पों का प्रयोग स्वचालित होना चाहिए।

git यह निर्धारित करने के लिए एक निश्चित हेयूरिस्टिक का उपयोग करता है कि क्या कोई फ़ाइल चली गई है, यह अच्छा है लेकिन सही नहीं है।

— gbjbaanb

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

— तजार्ट

Answer 7

प्रदर्शन के संबंध में, Git या किसी अन्य DVCS का SVN पर एक बड़ा लाभ है जब आपको एक शाखा से दूसरी शाखा में स्विच करना होगा, या एक संशोधन से दूसरे में कूदना होगा। जैसा कि सब कुछ स्थानीय रूप से संग्रहीत किया जाता है, एसवीएन की तुलना में चीजें बहुत तेज होती हैं।

यह अकेला मुझे स्विच कर सकता है!

Comments

सहमत, git चेकआउट बहुत तेज है।

+1 यह इंगित करने के लिए कि शाखाओं /

— बदलावों के

Answer 8

इसके बजाय इस विचार को लटकाने पर कि "सर्वोत्तम प्रथाओं को लागू करने के लिए आपको डीवीसीएस की आवश्यकता नहीं है", क्यों नहीं माना जाता है कि एसवीएन वर्कफ़्लो एक वर्कफ़्लो है, जिसमें सर्वोत्तम प्रथाओं का एक सेट है, और जीआईटी / एचजी वर्कफ़्लो एक अलग वर्कफ़्लो है, सर्वोत्तम प्रथाओं के एक अलग सेट के साथ।

git bisect (और अपने मुख्य भंडार पर इसके सभी निहितार्थ)

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

git bisectक्षमता प्राप्त करने के लिए , आप अपनी स्वयं की सुविधा शाखा पर एक नई सुविधा विकसित करते हैं , इसे रीबेस करते हैं और इतिहास को साफ करते हैं (इसलिए आपके पास अपने इतिहास में कोई भी ज्ञात गैर-कार्यशील संशोधन नहीं है - बस परिवर्तनों का एक गुच्छा जो आपको मिलता है। समस्या को ठीक करना), और फिर जब सुविधा हो जाती है, तो आप इसे कार्यशील इतिहास के साथ मुख्य शाखा में विलय कर देते हैं।

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

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

Gitworkflows आदमी पेज workflows कि Git लिए बनाया गया है के लिए एक अच्छा परिचय है। इसके अलावा क्यों Git X से बेहतर है, git वर्कफ़्लो पर चर्चा करता है।

बड़ी, वितरित परियोजनाएँ

हमें अच्छे व्यवहार और अच्छी डिजाइन आदतों के साथ एक उच्च सहयोगी टीम में लेफ्टिनेंट की आवश्यकता क्यों है?

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

Comments

मुझे आपका पहला अंक नहीं मिला। क्या आपके पास कुछ संदर्भ हैं? पिछले एक के बारे में, मैं इस परियोजना को अलग-अलग घटकों में विभाजित करूंगा। मैंने कभी इतने बड़े प्रोजेट पर काम नहीं किया, एक ही प्रोजेक्ट पर मुझे जितने भी डेवलपर मिले , दो दर्जन हैं।

@Pierre। यह निश्चित रूप से परियोजना को अलग-अलग घटकों में विभाजित करने के लिए उचित है। चूंकि लिनक्स एक अखंड कर्नेल है, जिसका अर्थ है (अनिवार्य रूप से) कि सभी डिवाइस ड्राइवरों को एक ही रिपॉजिटरी में विकसित किया जाना है, भले ही प्रत्येक अनिवार्य रूप से एक अलग प्रोजेक्ट हो। इसी समय, वे चाहते हैं कि उनके अधिक अनुभवी वास्तुकारों के लिए चपलता के साथ व्यापक परिवर्तन हो जो इन सभी ड्राइवरों को छूते हैं, इसलिए उन्हें विभिन्न रिपॉजिटरी में तोड़ना एक दर्द होगा। इसलिए इन विभिन्न चिंताओं के प्रबंधन के लिए git (और लेफ्टिनेंट) उन्हें अच्छी तरह से सूट करते हैं।

— केन ब्लूम

आपको यह भी पढ़ने में दिलचस्पी हो सकती है कि मार्टिन फॉलर ने एसवीएन बनाम गिट और मर्क्यूरियल वर्कफ़्लोज़ के बारे में क्या कहा है। martinfowler.com/bliki/VersionControlTools.html

— केन ब्लूम

मैं कीड़े खोजने के लिए नियमित रूप से एसवीएन पर द्विभाजन करता हूं। Git के साथ एकमात्र अंतर यह है कि यह सभी स्वचालित नहीं है। लेकिन यह अकेले हमें स्विच करने के लिए पर्याप्त नहीं होगा।

— जेवियर नोडेट

छोटी टीमों के लिए गिट बाइट की प्रासंगिकता लगभग शून्य है। मैं इसे उस कर्नेल के लिए प्राप्त करता हूं, जहां विभिन्न लोगों के सैकड़ों बदलावों को एक बार में विलय किया जा रहा है और चीजों को तोड़ दिया जा रहा है, लेकिन जब आपके पास 5 की टीम होती है, तो आप आमतौर पर सभी लेकिन 2-3 संभावित अपराधी पैच को एक त्वरित नज़र के साथ समाप्त कर सकते हैं। लॉग इन करें।

— ब्लुकज

Answer 9

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

Comments

लेकिन आप बस एक डीवीसी के साथ एक केंद्रीय भंडार स्थापित कर सकते हैं (और आप सीवीसीएस के साथ ही अनुमतियों को कसकर नियंत्रित कर सकते हैं। तो क्या लाभ हैं?

— naught101

सच है, लेकिन केंद्रीय गिट रिपॉजिटरी को स्थापित करना मुश्किल हो सकता है यदि आप विंडोज वातावरण में हैं। मुझे लगता है कि यह बहुत ही एकमात्र है जिसके बारे में मैं सोच सकता था। हमें कॉर्पोरेट स्तर पर सीवीएस का उपयोग करने के लिए मजबूर किया गया था, इसलिए हमारे पास वास्तव में कोई विकल्प नहीं था।

— वादिम

Answer 10

मुझे DVCS के साथ कोई व्यक्तिगत अनुभव नहीं है, लेकिन मैं यहां से जो कुछ उत्तर और कुछ लिंक किए गए दस्तावेज़ों से इकट्ठा करता हूं, DVCS और CVCS के बीच सबसे बुनियादी अंतर उपयोग किए गए कार्य मॉडल का है

DVCS

डीवीसीएस का काम करने का मॉडल यह है कि आप अलग-थलग विकास कर रहे हैं । आप अपनी नई सुविधा / बगफिक्स को अन्य सभी परिवर्तनों से अलग कर रहे हैं, जब तक कि आप इसे बाकी टीम को जारी करने का निर्णय नहीं लेते। उस समय तक, आप जो चाहें चेक-इन कर सकते हैं, क्योंकि कोई और इसके साथ परेशान नहीं होने वाला है।

CVCS

CVCS (विशेष रूप से तोड़फोड़) में काम करने का मॉडल यह है कि आप सहयोगी विकास कर रहे हैं । आप टीम के अन्य सदस्यों के साथ सीधे सहयोग में अपनी नई सुविधा / बगफिक्स विकसित कर रहे हैं और सभी परिवर्तन तुरंत सभी के लिए उपलब्ध हैं।

अन्य अंतर

svnऔर git/ और के बीच अन्य अंतर hg, जैसे कि संशोधन बनाम परिवर्तन आकस्मिक हैं। संशोधन के आधार पर DVCS बनाना बहुत संभव है (जैसे कि सबवर्सन उनके पास है) या चेंज के आधार पर CVCS (जैसे Git / Mercurial उनके पास है)।

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

• मुझे सामान की जाँच का कोई डर नहीं है, क्योंकि मुझे कोई समस्या नहीं है, लेकिन इसे अधूरी, लेकिन मजबूर करने वाली स्थिति में लाना है।
• जब मैंने मर्ज-नर्क का अनुभव किया, तो यह उन स्थितियों में था जहां यह दोनों svnऔर git/ में हुआ होगा hg। उदाहरण के लिए, कुछ सॉफ्टवेयर के V2 को एक अलग VCS का उपयोग करके एक अलग टीम द्वारा बनाए रखा जा रहा था, जबकि हम V3 विकसित कर रहे थे। कभी-कभी, बगफिक्स को वी 2 वीसीएस से वी 3 वीसीएस में आयात करना होगा, जिसका मूल रूप से वी 3 वीसीएस (एक एकल बदलाव में सभी बगफिक्स के साथ) पर एक बहुत बड़ा चेक-इन करना था। मुझे पता है कि यह आदर्श नहीं था, लेकिन यह विभिन्न वीसीएस प्रणालियों का उपयोग करने के लिए एक प्रबंधन निर्णय था।

Comments

मुझे नहीं लगता कि अलग-थलग विकास वास्तव में डीवीसीएस का काम करने वाला मॉडल है। DVCS की एक महत्वपूर्ण विशेषता यह है कि टीम के अन्य सदस्य आपके स्थानीय परिवर्तनों को खींच सकते हैं या आपके स्थानीय भंडार को क्लोन कर सकते हैं। जब आप पसंद करते हैं, तो आपके परिवर्तन हमेशा उपलब्ध होते हैं , और आपके कीड़े सामूहिक तबाही का कारण नहीं बन सकते।

— फिलोसोडैड

@philosodad: यदि अन्य उस कोड की स्थिति को जाने बिना मेरी रिपॉजिटरी से कोड खींचते हैं, तो यह अभी भी कहर पैदा कर सकता है। फर्क सिर्फ इतना है कि इसकी जिम्मेदारी किसकी है। और मेरा कोड हमेशा उपलब्ध नहीं होता है। यह अभी भी इस बात पर निर्भर करता है कि क्या मेरे सिस्टम बाहरी पहुँच के लिए कॉन्फ़िगर किए गए हैं।

— बार्ट वैन इनगेन शानौ

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

— फिलोसोडैड

@philosodad: मुझे लगता है कि मैं इसे बेहतर और बेहतर समझना शुरू कर रहा हूं: हर कोई आपकी गड़बड़ी प्राप्त कर सकता है, जैसे कि सीवीसीएस में, लेकिन यह अब आपकी गलती नहीं है, क्योंकि आपने इसे उन पर नहीं धकेला। :-)

— बार्ट वैन इनगेन शेनॉ

अच्छी तरह की। लेकिन आम तौर पर, ऐलिस पहले क्लोन या शाखा करता है और फिर आपके परिवर्तनों को मर्ज कर देता है, जिससे यह दिखावा करना आसान हो जाता है कि उसने आपका बगिया कोड पहले कभी नहीं देखा था!

— फिलोसोडैड