2008-08-25 14 views
37

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

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

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

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

Intro to Distributed Version Control

Wikipedia Entry

उत्तर

30

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

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

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

+0

डीवीसीएस कम विलय संघर्ष कैसे करता है? और यदि आप एक नियमित वीसीएस में विलय करते हैं, तो आप बैक अप नहीं ले सकते हैं और इसे फिर से कर सकते हैं और उस परिणाम में जांच सकते हैं। –

+0

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

+2

दूसरी तरफ एक डीवीसीएस विवादों को विलय करने से बचाता है यह है कि इसमें पिछले विलय का इतिहास है, इसलिए यदि कोई बदलाव पहले से ही विलय हो गया है, तो सिस्टम इसे फिर से कोशिश नहीं करता है और विलय नहीं करता है, जबकि सबवर्सन जैसे सामान्य वीसीएस सिस्टम में उसमें परिवर्तन शामिल होगा एक संघर्ष की संभावनाओं में वृद्धि, विलय। – tghw

1

के साथ अलग अलग कनेक्शन के एक नंबर से अधिक SourceForge और अन्य सर्वर के साथ सववर्सन का उपयोग करना मध्यम आकार की टीमों और यह बहुत अच्छी तरह से काम कर रहा है।

0

, सबवर्सन

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

1

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

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

+0

जबकि मुझे शायद ही कभी लगता है कि मैं पूरी तरह से कुछ भी कर रहा हूं, और लंबे समय तक लाभ के लिए चीजों को बदलने के लिए खुला हूं। सोमवार सुबह या शुक्रवार दोपहर के अलावा। –

+0

खैर, "पूर्णतया सर्वोत्तम तरीका" आमतौर पर एक कल्पित अवधारणा है। हालांकि, आप उपयोगकर्ता और डेवलपर प्रतिक्रिया से सफलता को माप सकते हैं। यदि आपकी टीम साथ मिल रही है और आपके उपयोगकर्ता खुश हैं, तो नाव को भारी क्यों रॉक करें? मुझे पता नहीं है, मुझे लगता है कि मैं निजी परियोजनाओं पर चीजों को "कोशिश" करना चाहता हूं। –

2

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

5

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

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

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

+1

क्या वीसीएस सर्वर-साइड विलय करता है? यह एक बहुत ही खराब डिजाइन पसंद की तरह लगता है। मैंने सीवीएस, वीएसएस, एसवीएन, गिट और डार्क्स के साथ काम किया है, और हालांकि उनमें सभी की त्रुटियां हैं, वे गलती नहीं करते हैं - वे सभी क्लाइंट साइड पर विलय करते हैं। – finnw

4

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

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

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

  • मैं एक सह कार्यकर्ता के साथ एक सर्वर का हिस्सा हैं और हम अपनी परियोजना के लिए एक मुख्य रेपो रहते हैं।
  • कुछ ओएसएस परियोजना मैं पर काम के लिए, हम मर्क्युरियल (Hg निर्यात) और परियोजना की maintener साथ हमारे काम का पैच बनाने के सिर्फ उन्हें भंडार पर लागू होते हैं (Hg आयात)

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

3

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

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

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

+0

पिछले दस वर्षों से किसी भी उचित वीसीएस ने समवर्ती संपादन की अनुमति दी है। मुझे फ्लैशबैक या दुःस्वप्न मत दो। –

+0

+1 दो वीसीएस का उल्लेख करने के लिए मैंने पहले नहीं सुना था :-) – finnw

6

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

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

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

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

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

1

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

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

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

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

2

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

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

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

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

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

+1

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

5

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

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

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

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

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

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

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

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

0

डार्क्स 2.1.0 का उपयोग कर रहा था और मेरी परियोजनाओं के लिए यह बहुत अच्छा था। प्रयोग करने में आसान। प्यार चेरी चुनने प्यार।

3

ने एक बड़ी परियोजना (जीएचसी) और कई छोटी परियोजनाओं के लिए डार्क्स का उपयोग किया है। मेरे पास डार्क के साथ प्यार/घृणा संबंध है।

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

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

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

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

+1

सभी के रूप में डार्क्स न लें और सभी डीवीसीएस को समाप्त न करें। वाकई, यह शायद सबसे खराब DVCS है, मुख्य रूप से शौकियों के लिए एक खिलौना। अगर आप वास्तव में देखना चाहते हैं कि ये चीजें क्या कर सकती हैं तो मैं गिट या मर्कुरियल का सुझाव दूंगा। "पैच के सिद्धांत" के लिए – BubbaT

+0

, एक व्यक्ति जो गणितीय भौतिक विज्ञान के रूप में प्रशिक्षित होता है, मुझे इसके लिए बहुत अधिक पदार्थ नहीं दिखता है। माली यह अवलोकन है "यदि पैच यात्रा करते हैं, इससे कोई फर्क नहीं पड़ता कि पैच किस प्रकार लागू होते हैं"। वाह suprise, especial; ly पर विचार है कि पैच कार्यों के रूप में देखा जा सकता है। – BubbaT

+2

गिट एक क्रूर मजाक है। यह कुछ चीजें शानदार ढंग से करता है, लेकिन यह एक लचीला वर्कफ़्लो का वादा करता है जो इसे वितरित नहीं करता है। और यह शुरुआती और सूखे शुरुआती लोगों के लिए तैयार है। हाल ही में एक गैर-बेकार रेपो को धक्का देने की कोशिश की? –

0

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

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

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

1

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

0

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

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

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

संबंधित मुद्दे