एसवीएन का खराब उपयोग करना - क्या मरक्यूरियल जवाब है?

13

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

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

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

version-control svn mercurial

— वेन मोलिना
स्रोत

13

HgInit - यह तोड़फोड़ फिर से शिक्षा के साथ शुरू होता है, जो मुझे लगता है कि आप उपयोगी पाएंगे।

— यानिस

20

क्या आप डरते नहीं हैं कि वे एचजी के खराब उपयोग के साथ-साथ समाप्त हो जाएंगे?

— ऊद

6

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

— maple_shaft

2

@WayneM एक DVCS पर SVN का उपयोग करने के लिए चुनना जरूरी नहीं है कि यह गलत है। कुछ लोगों (खुद को शामिल किया गया) को एसवीएन में विलय के साथ कोई समस्या नहीं है और यह पाते हैं कि डीवीसीएस की गयी जटिलता कथित लाभ को बढ़ाती है, खासकर यदि आप एक छोटे से स्थानीय टीम हैं। मैं शायद डीवीसीएस को बहुत गंभीरता से नहीं लूंगा जब तक कि मैं एक बड़ी विकास टीम पर समाप्त नहीं हो जाता जहां विलय एक बहुत बड़ा दर्द बिंदु है।

— maple_shaft

4

@maple_shaft I will probably not take DVCS very seriously until I end up on a large development teamया जब तक आप किसी वितरित टीम पर समाप्त नहीं हो जाते। हम 3 स्थानों (और कभी-कभी 5, जब हम बिस्तर से बाहर निकलने का मन नहीं करते हैं) से काम करने वाली एक छोटी टीम (5 लोग) हैं, और svn से hg में स्विच करना एक स्वागत योग्य था ...

— yannis

15

हाँ।

यदि आप "एसवीएन" को अपने ओपी में "पेरफोर्स" से बदल देते हैं, तो आपको वह स्थिति मिल गई है जब मैंने खुद को पाया जब मैंने अपना वर्तमान काम शुरू किया था, यहां तक कि मैनुअल-परिवर्तन कॉपी करने के लिए भी। दो साल हम मर्क्यूरियल पर हैं और हर कोई इससे सहमत है कि यह एक महान बदलाव है।

हमारे पास प्रति समर्थन मामले को शाखा देने और मर्ज करने की क्षमता है , जो कि QA के लिए अविश्वसनीय रूप से उपयोगी है, और जब भी हम फिट देखते हैं, तो किसी भी संख्या में फैली शाखाओं और रिपॉजिटरी को बनाने की क्षमता, जिसे हम अपने CI सर्वर में फिर से बना और सत्यापित कर सकते हैं, फिर तैनात कर सकते हैं क्लाउड परीक्षण वातावरण और कार्यक्षमता की जाँच करें। मन की शांति के संदर्भ में यह बहुत लाभकारी है कि जब हम एक लाइव तैनाती करते हैं, तो हमें लगभग 100% यकीन है कि यह काम करेगा (पर्यावरण / डीबी मुद्दे, जो स्पष्ट रूप से वीसीएस के दायरे से बाहर हैं)।

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

Hginit साइट के बारे में टिप्पणी भी स्पॉट पर है, एक संस्करण नियंत्रण वर्कफ़्लो की रूपरेखा के रूप में जो वास्तव में काम करता है (यह मानते हुए कि आप इसे अपनी कंपनी के विशेष क्यूए वर्कफ़्लो के लिए समायोजित करते हैं)।

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

मैं DCVS का उपयोग करने के लिए टीम आकार और टीम वितरण के बारे में टिप्पणियों से सहमत नहीं हूं। वास्तव में, यह CODE वितरण के बारे में है। यदि आपके पास समानांतर में कई विकास चक्र हो रहे हैं, तो या तो विरासत प्रणाली पर मामलों का समर्थन करें, या सुविधाओं का एक गुच्छा या यहां तक कि नए सिस्टम (जो आप इसे करते हैं) की आवाज से, आपको DVCS का उपयोग करने से लाभ होगा।

— एड जेम्स
स्रोत

3

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

— इज़काटा

1

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

— एंजेलो

2

@ ईडवूडकॉक: पेरफोर्स किसी भी वीसीएस की सबसे खराब शाखा हो सकती है जो अभी भी उपयोग में है। एसवीएन में ब्रांचिंग ज्यादा आसान है।

— केविन क्लाइन

1

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

— एंजेलो

1

@ क्रिस यह दृष्टांत एक मानक वीसीएस पर अधिक लागू होता है जहां ब्रांचिंग की लागत होती है। साथ ही, यह ब्रांचिंग, कमिटिंग, फिर मर्जिंग के बारे में बात कर रहा है, जो <i> आप हर बार DVCS में क्लोन </ i> करते हैं। इसके अलावा, मैंने अभी यह रेखांकित किया है कि दृष्टिकोण वास्तव में हमारे लिए क्यों काम करता है; कार्यप्रणाली के बारे में हठधर्मी होना काफी मूर्खतापूर्ण है।

— एड जेम्स

21

एक अलग उपकरण शायद आपकी समस्या को हल करने वाला नहीं है, मैं कहूंगा कि आपको इस लेख को पढ़ना चाहिए, मैंने इसे सबसे अधिक उपयोगी पाया:

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

मुझे लगता है कि लेख का मुख्य बिंदु यहां प्रस्तुत है, लेकिन कृपया इसे पढ़ें:

अंत में: उपकरण के बारे में वास्तव में नहीं

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

— काली बर्फ
स्रोत

6

+1, यह वास्तव में टूल के बारे में नहीं है। SVN पूरी तरह से सक्षम है जैसा कि लागू होता है।

— एंजेलो

1

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

— अलेक्जेंडर गल्किन

यह वास्तव में औजारों के बारे में नहीं है, जब तक कि आपको स्रोत नियंत्रण प्रदाता की सराहना करने के लिए श्रेष्ठ व्यक्ति न मिलें, जैसे कि github, bitbucket

— Chris S

3

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

— मार्क बूथ

10

प्रौद्योगिकी शायद ही कभी इस तरह की समस्या को हल करती है।

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

क) पर्याप्त रूप से या बेहतर
ख) अपर्याप्त रूप से, लेकिन तोड़फोड़ के आपके वर्तमान उपयोग से बेहतर है
ग) अब तक अपर्याप्त रूप से
d) अब से भी बदतर

ग) और घ) सबसे अधिक संभावित परिणामों की तरह ध्वनि। नीचे लिखें कि आपको क्यों लगता है कि आप) या बी) में समाप्त हो जाएंगे।

— एलेक्स
स्रोत

5

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

— ब्रायन नॉब्लुच
स्रोत

3

नहीं, उपकरण कार्यप्रणाली के प्रतिस्थापन नहीं हैं।

यदि आप एससीएम के रूप में तोड़फोड़ का उपयोग नहीं करते हैं , तो आप मर्क्यूरियल का भी उपयोग नहीं कर सकते हैं (और यह शायद सबसे अधिक होगा)

— आलसी बेजर
स्रोत

2

एसवीएन वह कर सकता है जो आपको करने की आवश्यकता है और घबराए हुए भुगतान के लिए घोड़ों को मध्य-धारा बदलने की कोई आवश्यकता नहीं है।

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

वहाँ कुछ चीजें हैं जो मुझे पता है कि लोगों ने सफलतापूर्वक कोशिश की है। शायद उनमें से एक आपकी टीम के लिए काम करेगा:

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

(*) "नए वीसीएस" से मुझे जरूरी नहीं कि भाड़े या गिट का मतलब है, यह एसवीएन (सही किया गया) भी हो सकता है।

— एंजेलो
स्रोत