version control क्या आप वितरित संस्करण नियंत्रण का उपयोग करते हैं?




version-control dvcs (18)

मैं उन लोगों से सुनना चाहता हूं जो वितरित संस्करण नियंत्रण (उर्फ वितरित संशोधन संशोधन, विकेंद्रीकृत संस्करण नियंत्रण) का प्रयोग कर रहे हैं और वे इसे कैसे ढूंढ रहे हैं। आप क्या उपयोग कर रहे हैं, Mercurial, Darcs, Git, बाजार? क्या आप अभी भी इसका उपयोग कर रहे हैं? यदि आपने अतीत में क्लाइंट / सर्वर आरसीएस का उपयोग किया है, तो क्या आप इसे बेहतर, बदतर या सिर्फ अलग पा रहे हैं? आप मुझे बता सकते हैं कि मुझे बैंडविगन पर कूदने के लिए क्या मिलेगा? या उस बात के लिए कूद, मुझे भी नकारात्मक अनुभव वाले लोगों से सुनने में दिलचस्पी होगी।

मैं वर्तमान में हमारे वर्तमान स्रोत नियंत्रण प्रणाली (सबवर्सन) की जगह देख रहा हूं जो इस प्रश्न के लिए प्रोत्साहन है

मुझे उस विशेष रूप से दिलचस्पी होगी जो इसे दूसरे देशों में सहकर्मियों के साथ उपयोग करते हैं, जहां आपकी मशीन एक ही समय में नहीं हो सकती है, और आपका कनेक्शन बहुत धीमा है

यदि आप सुनिश्चित नहीं हैं कि वितरित संस्करण नियंत्रण क्या है, तो यहां कुछ लेख हैं:

वितरित संस्करण नियंत्रण के लिए परिचय

विकिपीडिया प्रविष्टि

https://code.i-harness.com


सबवर्जन का उपयोग करना

सबवर्सन वितरित नहीं किया जाता है, जिससे मुझे लगता है कि मुझे एक विकिपीडिया लिंक की आवश्यकता है, अगर लोग इस बारे में निश्चित नहीं हैं कि मैं किस बारे में बात कर रहा हूं :)


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


मेरे कार्यस्थल पर हमने सीआईएस से लगभग 2 महीने पहले जीआईटी में स्विच किया था (मेरे अधिकांश अनुभव सबवर्सन के साथ हैं)। जबकि वितरण प्रणाली से परिचित होने में एक सीखने की अवस्था थी, मैंने पाया कि गीट दो प्रमुख क्षेत्रों में बेहतर है: काम के माहौल के लचीलेपन और विलय

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

क्योंकि विलीन क्लाइंट-साइड को निष्पादित किया जाता है, वे एक सर्वर-साइड मर्ज की शुरुआत करने से बहुत तेज और कम त्रुटि प्रवण होते हैं


मैं कुंडली स्रोत नियंत्रण प्रणाली का प्रयोग कर रहा हूं। मैं इसे अभी एक साल से थोड़ा अधिक उपयोग कर रहा हूं। यह वास्तव में एक VSC के साथ मेरा पहला अनुभव था।

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

मेरे पास लोगों के साथ अपना कोड साझा करने के 2 तरीके हैं:

  • मैं एक सहकर्मी के साथ एक सर्वर साझा करता हूं और हम अपने प्रोजेक्ट के लिए एक मुख्य रेपो रखते हैं।
  • कुछ ओ.एस.एस. परियोजना के लिए मैं काम करता हूं, हम अपने काम का मर्क्यूरिअल (एचजी निर्यात) के साथ पैच बनाते हैं और प्रोजेक्ट के रखरखाव को केवल रिपॉजिटरी (एचजी आयात) पर लागू करते हैं

साथ काम करना बहुत आसान है, फिर भी बहुत शक्तिशाली है लेकिन आम तौर पर, वीएससी चुनना वास्तव में हमारे परियोजना की जरूरतों पर निर्भर करता है ...


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

मैं मानसिकता का हूँ कि हमारे उपकरण को वास्तविक काम के रास्ते में कभी नहीं आना चाहिए; उन्हें काम आसान बनाना चाहिए तो, कुछ सिर के तेज़ अनुभवों के बाद, मैंने जमानत की। मैं नाव को कमाल करने से पहले अपनी टीम के साथ कुछ बहुत कठिन परीक्षण करने की सलाह देता हूं क्योंकि मॉडल एससीएम की दुनिया में सबसे ज्यादा devs की आदत से अलग है।


सोर्सफोर्ज और अन्य सर्वरों के साथ उप-धारा का उपयोग मध्यम आकार की टीमों के साथ कई अलग-अलग कनेक्शनों पर करते हैं और यह बहुत अच्छी तरह से काम कर रहा है


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

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

निजी तौर पर, मुझे लगता है कि टीमवेयर द्वारा लागू किया गया वितरित मॉडल या AccuRev द्वारा लागू हाइब्रिड मॉडल की तरह पूरी तरह से केंद्रीकृत समाधानों से बेहतर है। इसके लिए मुख्य कारण यह है कि कोई फाइल देखने या किसी अन्य उपयोगकर्ता द्वारा लॉक होने वाली फाइल होने की कोई धारणा नहीं है। इसके अलावा, उपयोगकर्ताओं को शाखाएं बनाने या परिभाषित करने की आवश्यकता नहीं है; उपकरण आपके लिए निहित रूप से ऐसा करते हैं जब बड़ी टीमों या अलग-अलग टीमयां हैं जो स्रोत फाइलों का योगदान करने या उनका रखरखाव करती हैं, तो इससे "टूल जनरेट किया गया" लॉकिंग से संबंधित टकरावों को हल किया जाता है और डेवलपर स्तर पर कोड परिवर्तन को अधिक समन्वित करने की इजाजत दी जाती है, जो अंततः किसी भी बदलाव को समन्वयित करना है। एक अर्थ में, वितरित मॉडल केंद्रित मॉडलों द्वारा शुरू की गई बेशक अनाज लॉकिंग के बजाय बहुत अधिक बेहतर दानेदार "लॉक" के लिए अनुमति देता है।


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

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

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

इनमें से कुछ हम सिर्फ शुरुआती 80 के दशक से बाहर निकल रहे हैं और कुछ आधुनिक संस्करण नियंत्रण तंत्र अपनाते हैं, लेकिन अधिकांश क्षेत्रों में गिट ने "यह सही किया"

मुझे लगता है कि आप जिस उत्तर की तलाश कर रहे हैं, उसके बारे में मुझे यकीन नहीं है, लेकिन गिट के साथ हमारा अनुभव बहुत ही सकारात्मक है।


जिस जगह पर मैं काम करता हूं, वहां हमने एसवीएन से बाज़ार तक जाने का फैसला किया (जीआईटी और मर्क्यूरीयल का मूल्यांकन करने के बाद) सरल आदेशों के साथ बाज़ार शुरू करना आसान था (140 आज्ञाओं की तरह जो कि git है)

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

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

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

एक बार जब आप समझते हैं कि यह डेवलपर की उत्पादकता में वृद्धि करेगा जब तक हर कोई यह नहीं समझता कि सभी के बीच असंगत व्यवहार होगा


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

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

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

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


मेरी कंपनी वर्तमान में सबवर्जन, सीवीएस, मर्क्यूरिअल और जीआईटी का उपयोग करती है

जब हमने पांच साल पहले शुरू किया तो हमने सीवीएस चुना था, और हम अभी भी हमारे मुख्य विकास के लिए मेरे डिवीजन में उपयोग करते हैं और रखरखाव शाखा जारी करते हैं। हालांकि, हमारे कई डेवलपर व्यक्तिगत रूप से व्यक्तिगत रूप से सीवीएस शाखाओं के दर्द (और विशेष रूप से उन्हें विलीन करने) के बिना निजी चौकक्तों का एक मार्ग के रूप में उपयोग करते हैं और हम लगभग 5 लोगों तक की कुछ शाखाओं के लिए Mercurial का उपयोग करना शुरू कर रहे हैं। एक अच्छा मौका है कि हम अंत में एक और साल में सीवीएस खोदेंगे। मर्क्यूरीयल का हमारा उपयोग व्यवस्थित हो गया है; कुछ लोग अभी भी इसे कभी भी छूते नहीं हैं, क्योंकि वे सीवीएस से खुश हैं। हर कोई जो मर्क्यूरीयल की कोशिश कर रहा है, उसे सीखने की वक्र के बिना, इसके साथ खुश रह गया है।

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

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

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

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

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

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


मेरी परियोजनाओं के लिए डारक्स 2.1.0 का प्रयोग किया गया और इसके महान। प्रयोग करने में आसान। चेरी उठा बदलाव प्यार


मैं अपने घर परियोजनाओं के लिए Mercurial के साथ खेल रहा हूँ अब तक, मैं इसके बारे में क्या पसंद करता हूं यह है कि मेरे पास कई रिपॉजिटरी हैं अगर मैं अपना लैपटॉप केबिन में लेता हूं, तो मुझे अभी भी संस्करण नियंत्रण मिल गया है, जब मैं घर पर सीवीएस चला रहा था। शाखाएं hg clone रूप में आसान है और hg clone पर काम कर रही है।


मैं काम पर और अपनी निजी परियोजनाओं में दोनों का उपयोग कर रहा हूं, और मैं इसके साथ खुश हूं। मैं देख रहा हूँ कि फायदे हैं:

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

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


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

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

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


हम बहु-साइट और डिस्कनेक्ट किए गए परिदृश्य दोनों के लिए वितरित संस्करण नियंत्रण ( प्लास्टिक एससीएम ) का उपयोग करते हैं।

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

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


एक बड़ी परियोजना (जीएचसी) पर और कई छोटी परियोजनाओं के लिए डैर्क्स का इस्तेमाल किया। मेरे पास डारक्स के साथ रिश्ते / नफरत है

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

Minuses: इतिहास की कोई धारणा --- आप 5 अगस्त को चीजों की स्थिति को ठीक नहीं कर सकते। मैंने वास्तव में कभी नहीं सोचा है कि पिछले संस्करण में वापस जाने के लिए डारक्स का उपयोग कैसे करें

डील-ब्रेकर: डार्क पैमाना नहीं है। मैं (और कई अन्य) ने डैरसी का उपयोग करते हुए जीएचसी के साथ बड़ी परेशानी में डाल दिया है मैंने इसे 9 महीने के लिए 100% सीपीयू उपयोग के साथ लटका दिया है, जिसमें 3 महीने के लायक परिवर्तन को खींचने का प्रयास किया गया था। पिछली गर्मियों में मुझे एक बुरी अनुभव हुआ था, जहां मैंने दो हफ्ते को डारक्स फंक्शन बनाने की कोशिश की और आखिरकार अपने सभी परिवर्तनों को हाथों से एक प्राचीन रिपॉजिटरी में फिर से चलाने का प्रयास किया।

निष्कर्ष: यदि आपको अपने शौक परियोजनाओं के लिए अपने आप को पैर में शूटिंग से बचाने के लिए एक सरल, हल्के तरीके से डरक्स बहुत अच्छा है। लेकिन डैर्क्स 2 में कुछ प्रदर्शन समस्याओं के साथ भी, यह अभी भी औद्योगिक ताकत सामग्री के लिए नहीं है मैं डैर्क्स में वास्तव में विश्वास नहीं करूँगा जब तक कि vaunted 'पैच के सिद्धांत' कुछ समीकरणों और कुछ अच्छे चित्रों की तुलना में थोड़ा अधिक है; मैं रेफ्रिड स्थल में प्रकाशित वास्तविक सिद्धांत को देखना चाहता हूं। यह पिछले समय है


वितरित स्रोत का उपयोग खुद को नियंत्रित नहीं करते हैं, लेकिन हो सकता है कि ये संबंधित प्रश्न और उत्तर आपको कुछ अंतर्दृष्टि देते हैं:





revision