विकेंद्रीकृत संस्करण नियंत्रण प्रणालियों के लिए व्यावसायिक मामला

Question

मैंने खोज की और कोई भी व्यावसायिक कारण नहीं खोज पाया कि git / mercurial / bazzr सिस्टम केंद्रीकृत सिस्टम (तोड़फोड़, लागू) से बेहतर क्यों हैं।

यदि आप एक गैर-तकनीकी व्यक्ति को डीवीसीएस बेचने की कोशिश कर रहे थे, तो आप डीवीसीएस के बढ़ते लाभ के लिए क्या तर्क देंगे ।

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

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

Comments

हम मामला बनाते हुए समान स्थिति में हैं और यह कहा जाना है, मुझे यकीन नहीं है कि वर्तमान में एक है।

— जॉन हॉपकिंस

git-svnअपनी आवश्यकताओं को पूरा कर सकता है ?

— JBRWilkinson

@JBRWilkinson मैंने अभी-अभी git-svn का इस्तेमाल किया है जो कि repositories के एक समूह को git में स्थानांतरित करने के लिए है। कंपनी के पास उन उपकरणों में बहुत अधिक निवेश नहीं है जो svn के साथ एकीकृत हैं, इसलिए यह बहुत समस्या नहीं थी।

— कीयो

संपादित करें - आपने अभी भी यह नहीं बताया है कि SVN आपको कैसे और क्यों विफल कर रहा है जैसे आपको लगता है कि आपको प्रतिस्थापन की आवश्यकता है। मेरा जवाब (उदाहरण के लिए) git बनाम svn के बारे में नहीं है , यथास्थिति को बदलने के लिए व्यावसायिक मामला खोजने के बारे में।

— मर्फ़

Answer 1

हम्म, एक प्रबंधक होने के नाते मेरे पास इस पर दो तत्काल "घुटने-झटका" प्रतिक्रियाएं हैं:

• यदि आपके पास पहले से ही अच्छे कारण नहीं हैं, तो आप ट्रेंडी होने के अलावा अन्य काम क्यों कर रहे हैं?
• इसी तरह, तोड़फोड़ इस तरह से कैसे विफल हो रही है कि आपको प्रतिस्थापन की आवश्यकता है?

मैं वास्तव में नकारात्मक नहीं हूं - मुझे लगता है कि संभवत: एक मामला बनाया जाना है (परिस्थिति पर निर्भर) लेकिन अगर मामला बस इतना है कि तोड़फोड़ की तुलना में "बेहतर" है तो आपके पास वास्तव में एक नहीं है।

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

मेरे दिमाग में, लाभ लचीलेपन में हैं, बेहतर विलय, निर्माण को तोड़ने के बिना स्थानीय कमिट करने की क्षमता। नुकसान नियंत्रण की कमी है और वही लचीलापन है।

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

हम्म, शायद यह पूरा जवाब एक टिप्पणी है? आपको अपने मामले को यहां (प्रश्न में) तोड़फोड़ के लिए (अपने परिवेश में) बनाने की जरूरत है ताकि हम यह देख सकें कि क्या हम व्यापार के मामले की पहचान करने में आपकी मदद कर सकते हैं।

---

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

Comments

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

— Matthieu M.

पूर्ण क्लोन बैकअप के बारे में अच्छी तरह से बनाया गया है। मैं स्वतंत्र रूप से मानता हूँ कि इस के कुछ क्षेत्र हैं जो मुझे अच्छी तरह से समझ में नहीं आते हैं क्योंकि मेरा "काम" सामान svn है और मेरा व्यापारिक व्यक्तिगत है और, अभी तक, कुछ हद तक सीमित है।

— मर्फ़

Answer 2

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

Comments

एक कारोबारी माहौल में, 'केंद्रीकृत सर्वर' में अतिरेक, बैकअप और प्रवेश के लिए जिम्मेदार होगा और इसे (और अन्य सभी सर्वर) जीवित रखने के लिए।

— JBRWilkinson

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

— माइकल शॉ

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

— मेसन व्हीलर

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

— इंका

और यह भी, मैं प्रतिबद्ध इतिहास के मूल्य को कम नहीं आंकूंगा। एक विशाल प्रणाली में यह देखने के लिए वास्तव में मूल्यवान हो सकता है कि किसने और क्यों कोड के लिए कुछ किया।

— तमसे सजेलेई

Answer 3

मुझे लगता है कि जब आप एक डेवलपर अकेले काम कर रहे हैं तब भी आप संस्करण नियंत्रण में वृद्धि उत्पादकता (और इस प्रकार लाभ) के लिए एक मामला बना सकते हैं।

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

Comments

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

— कार्सन 63000

तब आप एकीकरण नरक में होंगे जब आप अंततः अपने बदलावों को आगे बढ़ाएंगे। यह एक बुरी बात है अच्छी बात नहीं है।

— हेनरी

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

— डेविजॉन्स्टन

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

— जॉप J

क्या आप इन सभी चीजों के साथ (क) एसवीएन शाखाएँ या (ख) एकाधिक कार्य कॉपियाँ नहीं कर सकते हैं?

— JBRWilkinson

Answer 4

• शाखा-प्रति-बग
• आपके भिन्न पर कम विलंबता।
• जब आप सहकर्मी समीक्षा कर रहे हों, तो शाखा के इतिहास के माध्यम से बहुत तेज़ी से मनमाने ढंग से नेविगेट करने में सक्षम होना ।
• जब आपके पास केंद्रीकृत सर्वर तक पहुंच नहीं है, तब भी आपके पास पूरे इतिहास तक पहुंच है: आप कार्यालय में नहीं हैं, बिजली अभी बाहर गई है लेकिन आपके लैपटॉप की बैटरी अभी भी काम कर रही है, ...

ये चीजें आपको एकल और एक टीम दोनों में अधिक कुशलता से काम करने देती हैं। अधिक कुशल कार्य = तेजी से विकास का समय = बाजार के लिए तेज समय = लाभ।

Answer 5

मुझे अपने स्वयं के ब्लॉग से जोड़ने के लिए क्षमा करें, लेकिन मैंने इस विषय पर लेख लिखे हैं:

• क्यों टिप हमेशा संकलन करना चाहिए
• क्यों DVCS बेहतर केंद्रीय नियंत्रण प्रदान करता है
• DVCS से ब्रांचिंग बेहतर क्यों है
• क्यों वितरित ब्रांचिंग मॉडल आपके CVCS पर अच्छी तरह से काम नहीं कर सकते हैं ।

यदि आप उन्हें प्रासंगिक नहीं पाते हैं तो बेझिझक नीचे उतरें।

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

Comments

आपकी ब्लॉग प्रविष्टियाँ अच्छी तरह से लिखी गई हैं। मैंने अभी तक उन सभी को नहीं पढ़ा है। मुझे आश्चर्य है कि जब आपने Git और Hg को अधिक लोकप्रिय माना है तो आपने Bzr को क्यों चुना है। लोग धीमी गति से होने के लिए Bzr से नफरत करने लगते हैं। मैं भी संशोधन संख्या के बजाय ट्री हैश की वजह से गिट का प्रशंसक हूं, जो मुझे बहुत सुरक्षित लगता है। जब शाखाएँ मर्ज की जाती हैं तो bzr रेव नंबर नहीं मिलेगा?

— कीयो

@ कीयो, मैंने bzr को चुना क्योंकि मुझे खुद को DVCS सिखाना था और bzr सबसे नौसिखिया-मित्र है। मैंने तब से गति, सुविधाओं और स्थिरता के लिए गिट में बदल दिया है। बाज़ार ने भी अपने संशोधन किए हैं और विश्व स्तर पर विशिष्ट पहचानकर्ता हैं, वे केवल उपयोगकर्ता के लिए डिफ़ॉल्ट नहीं हैं। उनका संशोधन संख्या वास्तव में कोई उपयोग करने की तुलना में अलग हैं HEAD~1, HEAD~2आदि में Git। यह बहुत दुर्लभ है आपको वास्तविक हैश की आवश्यकता है, लेकिन यह पहली चीज है जिसे आप गिट में सीखते हैं और हमेशा आपके चेहरे पर होते हैं। उपयोगकर्ता से छुपाना जब तक कि आपको वास्तव में इसकी आवश्यकता न हो, एक कारण यह है कि bzr अधिक नौसिखिया अनुकूल है।

— कार्ल बेवफेल्ट्ट

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

— कीयो

Answer 6

DVCS के लिए मेरे तर्क ये हैं:

• ब्रांचिंग टूटी नहीं है, जिससे सुविधाओं को विकसित करने और मौजूदा उत्पादों को पैच रखने में कम घर्षण होता है। घर्षण से समय में पैसा खर्च होता है।

• आधुनिक प्रणाली में स्थानांतरित करना बेहतर रूप से अत्याधुनिक डेवलपर्स को आकर्षित करता है, जिससे बेहतर उत्पादों की संस्कृति पैदा होगी, जो व्यवसाय को अधिक उत्पादों को बेचने में सक्षम बनाता है।

• गैर-नेटवर्क कमिट्स तेजी से होते हैं , जिससे डेवलपर्स को अक्सर कमिट करने की अनुमति मिलती है, जिससे बग का पता लगाने और विश्लेषण करने में कठिनाई होती है।

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

Answer 7

मैं माफी माँगता हूँ अगर मैं समझ रहा हूँ, लेकिन मुझे व्यापार के मामले को बिना किसी अनिश्चितता के रखने की अनुमति दें:

SVN डेवलपर्स के जीवन को दयनीय बनाता है । और यह एक सॉफ्टवेयर व्यवसाय को दयनीय बना देता है।

... कई मायनों में जब तक वे एक DVCS का उपयोग शुरू नहीं एहसास होगा। यह सबसे महत्वपूर्ण व्यावसायिक मामला है जिसे संभवतः बनाया जा सकता है । क्यूं कर? खैर, अच्छे डेवलपर्स को खोजने और बनाए रखने की लागत की तुलना में , डीवीसीएस पर स्विच करने की लागत लगभग गैर-मौजूद है ।

निम्नलिखित को धयान मे रखते हुए:

• SVN (और अधिकांश CVCSes) में सभी लेकिन सबसे तुच्छ कार्यों के लिए नेटवर्क एक्सेस की आवश्यकता होती है। सबसे DVCSes में, नेटवर्क का उपयोग केवल तब होता है जब आप एक कर pushया pullआपरेशन। इसका मतलब है कि गैर-तुच्छ कमांड धीमी हैं । जब कोई आज्ञा हमेशा के लिए ले रहा हो तो आप क्या करते हैं? जब मैं प्रतीक्षा कर रहा होता हूं, मैं व्यक्तिगत रूप से प्रोग्रामर.से या हैकर समाचार ब्राउज़ करता हूं। सीधे शब्दों में कहें तो, DVCS प्रोग्रामर्स को यह पसंद करने पर ध्यान केंद्रित करने की अनुमति देते हैं कि वे क्या प्यार करते हैं: कंपनी का सॉफ्टवेयर लिखना ।
• SVN के पास बहुत हद तक शाखाओं में बँटने के लिए समर्थन है। शॉवर में अपने साबुन को गिराने के लिए जेलों का समर्थन है: आप इसे कर सकते हैं, लेकिन जब आप करते हैं तो आप चुदाई कर लेते हैं। इस प्रकार, एसवीएन आपके डेवलपर्स को परिवर्तन करने के लिए लगातार एक-दूसरे से लड़ने के लिए मजबूर करता है ।
• जब SVN डाउन होता है, तो यह डाउन हो जाता है। डेवलपर्स के लिए अपने काम करना बहुत मुश्किल हो जाता है अगर वे उन्हें बिल्कुल भी कर सकते हैं। इस प्रकार, SVN आपके डेवलपर्स को 100% बग-मुक्त होने के लिए आपके बुनियादी ढांचे पर निर्भर होने के लिए मजबूर करता है ।
• इन दिनों git तेजी से माइंडशेयर हासिल कर रहा है जबकि SVN तेजी से इसे खो रहा है। यदि एसवीएन पर डीवीसीएस का उपयोग करने के कोई लाभ नहीं हैं, तो प्रोग्रामिंग समुदाय उतनी तेजी से क्यों बदल रहा है?

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

(मुझे इस बात पर ध्यान देना चाहिए कि बोल्ड स्टेटमेंट वे विशेष हैं जिन पर आपको ध्यान केंद्रित करना चाहिए। बाकी सभी उन्हें प्रदान करते हैं)।

Comments

-1 - आप भव्य हैं और जब आप इसे लिखते हैं तो इसमें कुछ सच्चाई होती है कि यह इतनी नकारात्मक रूप से होती है कि तर्कपूर्ण विश्लेषण के बजाय एफयूडी पर कटाक्ष करना। क्या SVN धीमा है? केवल अगर रिपॉजिटरी विशाल है और नेटवर्क हिमनद है। क्या SVN मुझे काम करने से रोक रहा है - शुक्राणु, इसे कभी भी नीचे और NO के रूप में याद नहीं रख सकता क्योंकि मेरा कंप्यूटर स्रोत को संपादित / संकलित / चलाने के लिए रिपॉजिटरी के अस्तित्व पर निर्भर नहीं करता है। क्या SVN ब्रांचिंग और मर्जिंग खराब है? वाह लोगों की छोटी यादें हैं ... डीवीसीएस माइंडशेयर क्यों बन रहा है? कार्यक्षमता का एक मिश्मश - जो सुधरा है - और, स्पष्ट रूप से, फैशन।

— मर्फ़

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

— जेसन बेकर

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

— :)

आपके सभी बिंदु तथ्यों के बजाय राय के मामले हैं। मैं एक-एक कर दूंगा लेकिन टिप्पणियों में पर्याप्त जगह नहीं है। कैसे के बारे में आप फिर से जवाब के बिना भव्यता?

— हेनरी

@ हेनरी - प्रोग्रामर.से व्यक्तिपरक प्रश्न और उत्तर के लिए है। विषय == राय का मामला।

— जेसन बेकर

Answer 8

केवल एक चीज जो मैं सोच सकता हूं, वह यह है कि गिट बिना नेटवर्क कनेक्शन के काम करता है। बाकी सब कुछ भी अक्सर उन तकनीकी उपयोगकर्ताओं को बेचना मुश्किल होता है जो कुछ समय के लिए सक्सेसर या पेरफोर्स का उपयोग करते हैं।

Comments

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

— j_random_hacker

@j_random_hacker: VCS का बिंदु कोड परिवर्तनों को ट्रैक करना है। कोड पटरियों में परिवर्तन करना। यदि आप ऑफ़लाइन नहीं कर सकते, तो मेरा तर्क है कि ऑफ़लाइन रहते हुए आपका VCS काम नहीं करता है।

— डेनिथ

Answer 9

अंतर तब दिखता है जब परेशानी होती है

हमने 6 दशक पहले अपने दशक पुराने भंडार को पोर्ट करने के बाद स्विच किया था।

अब तक मैंने कुछ प्रयोग करने के बाद, निम्नलिखित पाया है:

• ब्रांचिंग और मर्जिंग लगभग दर्द रहित है। यह अलग-अलग सुविधाओं पर काम करना आसान बनाता है और एक दूसरे के पैर की उंगलियों पर कदम रखे बिना बगफिक्सिंग करता है। यह दिए गए बगफिक्स को कहीं और भी लागू करना बहुत आसान बनाता है।

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

• रिपोजिटरी इंटरैक्शन सरल है। सीवीएस के लिए आपको अनिवार्य रूप से हर समय पहुंच की आवश्यकता होती है जब भी आपको किसी जानकारी की आवश्यकता होती है। Git के लिए संपूर्ण रिपॉजिटरी स्थानीय रूप से उपलब्ध है जिससे कई चीजें तेजी से आगे बढ़ सकती हैं।

तो, लाभ दैनिक दिनचर्या में उतना नहीं है, लेकिन बहुत स्पष्ट है कि आपके पास कुछ सही ढंग से काम नहीं कर रहा है!

इसलिए, मेरा सुझाव है कि आपके व्यवसाय के मामले के लिए, आप देखें कि आपदा के समय आप क्या करेंगे ...

Comments

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

Answer 10

ब्रांचिंग और मर्जिंग में आसानी सबसे ठोस कारण है, लेकिन किसी को समझाने के लिए आपको उन्हें इस बात का ठोस उदाहरण देना होगा कि कैसे चीजों को बेहतर बनाता है।

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

Answer 11

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