क्या किसी छोटी कंपनी (15 डेवलपर्स) के लिए प्रबंधित स्रोत / संस्करण नियंत्रण का उपयोग नहीं करना असामान्य है? [बन्द है]


152

यह वास्तव में एक तकनीकी प्रश्न नहीं है, लेकिन स्रोत नियंत्रण और सर्वोत्तम अभ्यास के बारे में यहां कई अन्य प्रश्न हैं।

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

मैं थोड़ी देर के लिए किसी तरह के प्रबंधित स्रोत नियंत्रण के लिए धक्का देने की कोशिश कर रहा हूं, लेकिन मुझे कंपनी के भीतर इसके लिए पर्याप्त समर्थन नहीं मिल रहा है। मेरे मुख्य तर्क हैं:

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

मेरे प्रश्न हैं:

  1. क्या इस आकार के समूह के लिए स्रोत नियंत्रण नहीं होना सामान्य है?
  2. मुझे अब तक केवल स्रोत नियंत्रण नहीं होने के लिए अस्पष्ट कारण दिए गए हैं - क्या आप सुझाव देंगे कि स्रोत नियंत्रण को लागू नहीं करने के लिए मान्य हो सकता है , ऊपर दी गई जानकारी?
  3. वहाँ किसी भी अधिक कारण हैं के लिए स्रोत नियंत्रण है कि मैं अपने शस्त्रागार करने के लिए जोड़ सकते हैं?

मैं मुख्य रूप से यह महसूस करने के लिए कह रहा हूं कि मेरे पास इतना प्रतिरोध क्यों है, इसलिए कृपया ईमानदारी से जवाब दें।

मैं उस व्यक्ति को जवाब दूंगा जो मुझे विश्वास है कि उसने सबसे संतुलित दृष्टिकोण लिया है और तीनों सवालों के जवाब दिए हैं।

अग्रिम में धन्यवाद


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

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

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

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

2
15 देव शायद ही कोई छोटी दुकान हो।
लुई कोट्टमन

जवाबों:


108
  1. यह सामान्य नहीं हो सकता है , लेकिन जैसा कि ट्रेब कहता है , यह शायद उतना असामान्य नहीं है
  2. जैसा कि अन्य लोगों ने कहा है, आपके आकार में किसी कंपनी में स्रोत नियंत्रण नहीं होने के कोई वैध कारण नहीं हैं। तो आपको अमान्य कारणों की पहचान करने और उन पर हमला करने की आवश्यकता है :

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

    बी) अज्ञानता / भय / अनिश्चितता : "हम वास्तव में यह नहीं समझते हैं कि स्रोत नियंत्रण क्या है; हम इसका उपयोग करना नहीं जानते; हम नहीं जानते कि कौन सा उपकरण चुनना है; यह हमारी शैली को खराब करने वाला है" । यह एक कारण है कि मैं निश्चित रूप से उन्हें यहां नहीं भेजूंगा! यह आपके लिए अपने आप में एक बहुत लंबा आदेश हो सकता है, लेकिन मुझे लगता है कि आपके अवसरों को अधिकतम करने के लिए आपको एक 'टर्न-की' समाधान पेश करने की आवश्यकता है, और बहुत सारे वेरिएंट या विकल्प नहीं। आपको एक स्पष्ट विचार की आवश्यकता है: आप दिए गए टूल के साथ काम करने के लिए अपनी कार्य प्रक्रिया को कैसे फिट / बदलना चाहते हैं; कैसे / यदि आप मौजूदा कोड को वापस पोर्ट करने की योजना बनाते हैं; कितनी तेजी से आपको लगता है कि आप उपयोगकर्ताओं को 'ट्रेन' कर सकते हैं और उन्हें ऊपर-नीचे कर सकते हैं; आप संक्रमण अवधि का प्रबंधन कैसे कर सकते हैं (अगर वहाँ एक है); यह 'लागत' (घंटों में, यदि डॉलर में नहीं) की कितनी संभावना है।

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

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

(क्या आपने द चेंज फंक्शन के बारे में पढ़ा / सुना है ?)


2
(दुख की बात है) सामान्य और असामान्य के बीच के बीच के अंतर के लिए धन्यवाद। +1
कीपला

29
अज्ञान / मूर्ख के लिए +1। यदि आप एक पेशेवर सॉफ़्टवेयर डेवलपर हैं, तो SCM का उपयोग नहीं कर रहे हैं, तो आप नहीं हैं। अवधि।
क्रिस थॉर्नटन

2
जिज्ञासा से बाहर, स्रोत नियंत्रण के लिए प्रति व्यक्ति $ 300 का भुगतान कौन करेगा (वेलुट, आपकी विकि लिंक के अनुसार), जब अनगिनत मुफ्त अनुप्रयोग हैं?
रोब

11
बिंदु 2 पर: मुझे स्रोत नियंत्रण का उपयोग नहीं करने के लिए किसी भी आकार की टीम (1 की एक टीम शामिल है) का कोई वैध कारण नहीं दिखता है ...?
जेम्स खौर

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

185

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

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

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

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


45
दुर्भाग्य से, अक्षम्य असामान्य के बराबर नहीं है ...
मार्जन वेनेमा

6
यह उल्लेख करने के लिए नहीं कि निशुल्क स्रोत नियंत्रण प्रदाता हैं, इसलिए ऐसा नहीं है कि यह कार्रवाई का एक महंगा कोर्स है।
मंटोरोक

9
यह महंगा हो सकता है जहां तक ​​लोगों को अपनी आदतों, वर्कफ़्लो और प्रक्रियाओं को बदलने के लिए मिल रहा है।
15:19 बजे user1936

4
@Rook: बिल्कुल। लेकिन मेरे पास एक सुरक्षा जाल होगा जिसकी मुझे आवश्यकता नहीं है जो मेरे पास नहीं है। मैं बहुत पहले से प्रोग्रामिंग कर रहा था, मुझे पता था कि एक संस्करण नियंत्रण प्रणाली क्या थी। हालांकि यह एक आवश्यकता नहीं है, अपने आप को एक अच्छे उपकरण से वंचित करना बेवकूफी है।
जॉन पुरडी

12
मैं केवल डेवलपर होने पर भी स्रोत नियंत्रण के बिना विकसित होने की कल्पना नहीं कर सकता ।
webbiedave

34

क्या इस आकार के समूह के लिए स्रोत नियंत्रण नहीं होना सामान्य है?

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

मुझे अब तक केवल स्रोत नियंत्रण नहीं होने के लिए अस्पष्ट कारण दिए गए हैं - क्या आप सुझाव देंगे कि स्रोत नियंत्रण को लागू नहीं करने के लिए मान्य हो सकता है, ऊपर दी गई जानकारी?

अच्छी चर्चा के लिए SO पर यह प्रश्न देखें । स्वीकृत उत्तर कहता है:
"संस्करण नियंत्रण का उपयोग न करने के कोई अच्छे कारण नहीं हैं। कोई नहीं।"

क्या स्रोत नियंत्रण के कुछ और कारण हैं जो मैं अपने शस्त्रागार में जोड़ सकता हूं?

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


"एक महत्वपूर्ण संख्या नहीं है" ... हम्म ... एक ही कोड आधार पर 15 देवों के साथ ? जहां मैं हूं, हमने SCC को तब जोड़ा जब हम थे ... समान कोड आधार पर 5 + 2 देव और हमने महसूस किया कि इसके लिए उच्च समय था । मुझे यकीन है कि एक ही कोड आधार पर 15 devs और कोई SCC अत्यधिक असामान्य है :-)
मार्टिन Ba

3
@ मॉर्टिन: यह 15 लोगों को खोजने के लिए असामान्य नहीं है, जो सभी यहां नहीं आविष्कार किए गए सिंड्रोम से पीड़ित हैं ... मुझे लगता है कि शायद सभी छोटे (<20 कर्मचारियों) कंपनियों के 5% का कोई स्रोत नियंत्रण नहीं है। मुझे उम्मीद है कि आपका अनुभव फार्म मेरा ;-)
ट्रेब

+1 असामान्य नहीं, दुर्भाग्य से।
जोनास

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

27

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

बस एक उपकरण के लिए जाना जो आपकी मदद करता है। आकार हर जगह मायने नहीं रखता। गुणवत्ता हर जगह मायने रखती है।


4
+1, मैं वर्तमान में एक डेवलपर टीम हूं और मैं स्रोत नियंत्रण का उपयोग करता हूं। मैं भी खाना पकाने के व्यंजनों और मेरे फिर से शुरू जैसे सॉफ्टवेयर विकास से संबंधित व्यक्तिगत दस्तावेजों का प्रबंधन करने के लिए घर पर स्रोत नियंत्रण का उपयोग करता हूं।
मेपल_शफ्ट

1
+1, छोटी दुकानों के बहुत सारे ज़िप फ़ाइलों को उनके संग्रह के रूप में उपयोग करना शुरू करते हैं। यह सोचकर कि "मैं इस बिंदु पर वापस जाना चाहता हूं, इसलिए मैं पूरी बात को दोहराऊंगा"। यह समान नहीं है, बिल्कुल नहीं। एक बार जब आप SCM से परिचित हो जाते हैं, और महान उपकरण जो शीर्ष पर निर्मित होते हैं (लॉग, भिन्न, दोष, आदि ..), आप कभी वापस नहीं जाएंगे।
क्रिस थॉर्नटन

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

1
Imagine of a single developer, who might have removed some code and feels that the code is now required. Can he get the old code back?हाँ, मैं अभी कुछ हफ़्ते पहले अपने द्वारा लिए गए अंतिम बैकअप का उपयोग करता हूं, और जब भी मैं कोई बड़ा बदलाव करना चाहता हूं, तो मैं बैकअप लेता हूं। कुछ वर्षों में मुझे अभी तक असफल नहीं हुआ है, और कभी भी ज़रूरत नहीं है (या मुझे लगा जैसे मुझे इस्तेमाल करना चाहिए) स्रोत नियंत्रण ...
मेहरदाद

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

17

ऐसा लगता है कि आप पहले से ही संस्करण नियंत्रण की एक प्रणाली का उपयोग कर रहे हैं, लेकिन बहुत अच्छा नहीं है। लोग पहले से ही आवश्यकता संस्करण नियंत्रण को पहचानने लगते हैं। आपको बस उन्हें अगले स्तर पर लाने की आवश्यकता है - सॉफ्टवेयर संस्करण नियंत्रण।

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

  • स्प्रेडशीट में परिवर्तन दर्ज करने के बजाय, एससीएम सिस्टम न केवल क्या बदला, बल्कि किसने और क्यों बदला, इस पर नज़र रखता है।

  • एक बोनस के रूप में, आप कोड के जीवन के किसी भी बिंदु पर वापस जा सकते हैं और देख सकते हैं कि वास्तव में क्या था।

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

जैसा कि अन्य लोग पहले ही कह चुके हैं, मैं कुछ प्रतिरोधों की उम्मीद करूंगा, इसलिए मैं सिस्टम का उपयोग उस सामान पर करूंगा जो मैं कर रहा हूं।

(BTW, मैंने वास्तव में एसवीएन के तहत अपना रिज्यूमे और अन्य दस्तावेज रखे हैं। फिर से, मुझे कई बार कॉन्फ़िगरेशन और एकीकरण प्रबंधकों की भूमिका निभाई गई है।)


9

मुझे अब तक केवल स्रोत नियंत्रण नहीं होने के लिए अस्पष्ट कारण दिए गए हैं - क्या आप सुझाव देंगे कि स्रोत नियंत्रण को लागू नहीं करने के लिए मान्य हो सकता है , ऊपर दी गई जानकारी?

  • आपके द्वारा विकसित किया जा रहा उत्पाद एक संस्करण नियंत्रण प्रणाली है; प्रबंधक मौजूदा उत्पादों को नए उत्पाद के डिजाइन और कार्यान्वयन को प्रभावित करने से रोकने के बारे में चिंतित हैं।

  • BASE कूद और बैल के साथ चलने के सप्ताहांत के बीच, रोमांच चाहने वाले प्रबंधकों को यह सोचकर काम करने का आनंद मिलता है कि क्या सब कुछ अभी भी नरक में चला गया है।

  • अवतरण शत्रुतापूर्ण अधिग्रहण। कौन इस तरह से प्रबंधित एक सॉफ्टवेयर विकास संगठन का अधिग्रहण करना चाहेगा?

क्या स्रोत नियंत्रण के कुछ और कारण हैं जो मैं अपने शस्त्रागार में जोड़ सकता हूं?

  • आप पहले से ही संस्करण नियंत्रण कर रहे हैं, लेकिन आप वर्तमान में इसे कम से कम कुशल, सबसे अधिक श्रम-गहन, सबसे अधिक त्रुटि वाले तरीके से कल्पना करने योग्य बना रहे हैं। VCS के उपयोग से पैसे की बचत होगी, समय की बचत होगी, और गुणवत्ता में सुधार होगा।

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

  • कई डेवलपर्स एक ही समय पर एक ही फ़ाइल पर काम कर सकते हैं और बहुत अधिक परेशानी के बिना मतभेदों को सुलझा सकते हैं। परिवर्तन को VCS के बिना करना संभव है, लेकिन उस मामले में किसने, कब और क्यों बदला, इस पर नज़र रखना लगभग असंभव है।

  • डेवलपर्स को नए विचारों की कोशिश करने की स्वतंत्रता देता है, यह जानकर कि वे किसी भी समय किसी भी संस्करण को पुनर्प्राप्त कर सकते हैं।

  • बेहतर प्रक्रिया से प्रतिभाशाली डेवलपर्स को काम पर रखना और बनाए रखना आसान हो जाता है।


1
बिंदु दो पर, कई वीसीएस डेल्टास को बचाते हैं, लेकिन गिट फ़ाइल के प्रत्येक अद्वितीय हैश के लिए पूरी फ़ाइल को सहेजता है। लेकिन यह वास्तव में मायने नहीं रखता है; डिस्क स्थान सस्ता है और स्रोत कोड छोटा है। gitready.com/beginner/2009/02/17/how-git-stores-your-data.html
जेम्स

8

क्या इस आकार के समूह के लिए स्रोत नियंत्रण नहीं होना सामान्य है?

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

मुझे अब तक केवल स्रोत नियंत्रण नहीं होने के लिए अस्पष्ट कारण दिए गए हैं - क्या आप सुझाव देंगे कि स्रोत नियंत्रण को लागू नहीं करने के लिए मान्य हो सकता है, ऊपर दी गई जानकारी?

मुझे लगता है कि आपने केवल अस्पष्ट कारणों को सुना है क्योंकि संस्करण नियंत्रण का उपयोग नहीं करने के लिए कोई वैध कारण नहीं हैं।

क्या स्रोत नियंत्रण के कुछ और कारण हैं जो मैं अपने शस्त्रागार में जोड़ सकता हूं?

हां, इसके कई कारण हैं।

  1. ब्रांचिंग आपको अन्य विकास के साथ हस्तक्षेप किए बिना नई कार्यक्षमता विकसित करने की संभावना देता है।
  2. प्रत्येक कमिट आपको इस बात की जानकारी देता है कि वास्तव में क्या बदला गया है, उस बदलाव को किसने किया और कब यह बदलाव किया गया।
  3. आप आसानी से बगफिक्स कर सकते हैं, और उन्हें ग्राहकों को तैनात कर सकते हैं, और अधूरी नई कार्यक्षमता को छोड़ सकते हैं।
  4. यदि ग्राहक नए संस्करण में जाने से डरते हैं, तो आप विभिन्न संस्करणों को बनाए रख सकते हैं।
  5. आप एक ही परियोजना पर काम कर सकते हैं (यहां तक ​​कि समान स्रोत फ़ाइलें!) आसानी से।
  6. आप उस गलती के बाद परिवर्तनों को संरक्षित करने के साथ आसानी से एक गलती को वापस कर सकते हैं।

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

6

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


यह एक ऐसी चीज है जिससे मुझे फायदा होगा। मैंने केवल स्रोत नियंत्रण के लाभों के बारे में पढ़ा है, लेकिन इसे कभी भी अपने लिए अनुभव नहीं किया है। मैंने घर पर एसवीएन स्थापित करने पर विचार किया है (लेकिन वर्तमान में मेरा घर बना रहा है और ज्यादा समय नहीं है ..!)
ऑलिव-क्लेयर

5

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

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


4
हां, इसका कोई कारण नहीं है कि इसे स्वयं उपयोग न करें, फिर संयोग से एक सहकर्मी को अपनी शक्ति दिखाएं जब वह कम से कम उम्मीद करता है।
gtrak

5

मेरी कंपनी संस्करण नियंत्रण के लिए GIT का उपयोग करती है। कंपनी एक डेवलपर, एक सीईओ, एक सुरक्षा गार्ड, एक सफाई महिला और एक रिसीवर है। वे सब मेरे हैं। स्रोत संस्करण नियंत्रण हर समय जरूरी है।


5

मैं अपने आप से बहुत सारी परियोजनाओं पर काम करता हूं और मैं अभी भी संस्करण नियंत्रण का उपयोग करता हूं। आकार कोई फर्क नहीं पड़ता। यह हमेशा संस्करण नियंत्रण करने में मदद करता है।

जोएल टेस्ट में # 1 पर एक कारण है: http://www.joelonsoftware.com/articles/fog0000000043.html

इसके अलावा, यह संभव सूची में # 2 और # 3 बनाता है।


4

हम कुछ साल पहले एक 6 व्यक्ति टीम के साथ एक समान स्थिति में थे। डेवलपर्स में से एक ने एसवीएन को एक देव सर्वर पर स्थापित करने का कदम उठाया जहां साझा फ़ोल्डर था और बस इसका उपयोग करना शुरू कर दिया।

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


4

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


3

मैं सोच भी नहीं सकता कि 15 डेवलपर बिना किसी स्रोत नियंत्रण के कैसे काम कर सकते हैं। हालाँकि, इससे:

(...) अपने स्रोत कोड की मेजबानी के लिए एक नेटवर्क शेयर का उपयोग करता है (...)

मुझे लगता है कि आपने वीएसएस ( जैसे साझा फ़ोल्डर के आधार पर) का अपना गरीब-आदमी का संस्करण नियंत्रण बनाया है । यह जोखिम भरा है और कुशल नहीं है।

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


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

1
@ मिचैलब्लैकबर्न: मैं सहमत हूं। मैंने अपना आत्म स्पष्ट नहीं किया। मैं प्रशिक्षण और चीजों को स्थापित करने के लिए 2 दिनों के बारे में सोच रहा था (सेटअप रेपो, आयात कोड, आदि)
मिशैल harajer

3

अगर मैं दिन में कई बार नहीं करता हूं, या कम से कम घर से बाहर जाने से पहले, मुझे ऐसा लगता है .. याद आ रही है, कुछ गलत है।

मैंने एक बार 1998 में सिर्फ 2 डेवलपर्स (me + long haired admin guy) के साथ एक कंपनी में काम किया था। तब भी हमने svn का इस्तेमाल किया था। यह सिर्फ इतना सुविधाजनक है।

अपने करियर में कई बार मैंने काम के दिनों को खो दिया क्योंकि मैंने cp के बजाय mv जैसा कुछ किया और फिर rm -rf। मुझे रोने दिया और निराशा में शहर की सड़कों पर घूमते हैं।

मैंने एसई में होने के अपने 13 वर्षों में 5 कंपनियों में काम किया, कुछ सम्मेलनों में रहा, और कभी भी संस्करण नियंत्रण का उपयोग नहीं करने वाली कंपनी का सामना नहीं किया।

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


1
svn1998 में मौजूद नहीं था।
फहीम मीठा

3

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

नेता अक्सर आधिकारिक प्रबंधन पदों पर नहीं होते हैं। लोग शीर्षक की परवाह किए बिना अच्छे, निर्णायक नेताओं का अनुसरण करेंगे।

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

ठीक है, फ़्लैशबैक मुझे मिल रहे हैं। बिदा देना। सौभाग्य।


धन्यवाद दोस्त। मुझे नेता की परिभाषा "सही काम करना" पसंद है, जो एक प्रबंधक की परिभाषा से अलग है "सही चीजें करना"। यानी प्रबंधक वह कर रहा है जो वह सही तरीके से कर रहा है, लेकिन ऐसा करना सही नहीं हो सकता है। नेता सही काम करता है, लेकिन अक्सर इसे सही करने के लिए प्रबंधक की आवश्यकता होती है। निश्चित रूप से एक +1 :)
जैतून-क्लेयर

2
  1. स्टॉपवॉच प्राप्त करें,
    • स्प्रेडशीट में आपके द्वारा खर्च किए गए समय को केवल संस्करणों को सिंक करने के लिए गिनें
    • उस समय की गणना करें जब आप टूटे हुए संस्करणों की मरम्मत करते हैं
    • हॉलवे में चिल्लाते हुए लोगों की संख्या गिनें " मैं main.c का संपादन कर रहा हूँ!, बस यह सुनिश्चित करने के लिए कि अभी और कोई नहीं है!"
    • ग्राहकों से आपको मिलने वाली शिकायतों की संख्या को गिनें क्योंकि उनके बगफिक्स में अन्य परिवर्तन शामिल हैं
    • रिलीज के समय में देरी को सिर्फ इसलिए गिनें क्योंकि आप संस्करणों को सिंक करने में असमर्थ थे
  2. इस डेटा के साथ एक पावरपॉइंट बनाएं, तुलना करें कि vcs कैसे काम करेगी।
  3. प्रबंधन दिखाएं

2

यह सिर्फ एक दुर्घटना होने का इंतजार है। आपके पास कोई कोड इतिहास नहीं है, और एक झपट्टा में गिर गया, आपके डेवलपर्स में से एक काम के महीनों को मिटा सकता है। एक छोटी सी कंपनी के रूप में आप इस तरह के झटके को बर्दाश्त नहीं कर सकते।

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

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


2

लॉर्डस्क्री, मैं लगभग एक ही तरह के विधेय में हूं, मेरी तत्काल टीम लगभग 15 डेवलपर्स है। मैं अविश्वास (लगभग डरावनी) में हूं कि स्रोत नियंत्रण का उपयोग नहीं किया जाता है। "हमें स्रोत नियंत्रण का उपयोग करना चाहिए" के लिए मेरी प्रारंभिक प्रतिक्रिया "हमारे पास लागू करने के लिए समय नहीं है"। मेरे लिए, जैसे अंडरवियर पहनना, स्रोत नियंत्रण वैकल्पिक नहीं है। कुछ महीनों के बाद, मुझे भी TFS को लागू करने की मंजूरी मिल गई है, जिसे ऑर्ग द्वारा चुना गया है क्योंकि यह एमएस है और 90 दिनों के परीक्षण के साथ आता है। निचला रेखा, स्रोत नियंत्रण की आवश्यकता के एक संगठन को समझाने के लिए बहुत मुश्किल है जब वे इसके बिना चुग रहे हैं। मैं डेवलपर्स को बताता हूं कि कभी-कभी आप खुद को फाइलों का बैकअप लेते हुए पाते हैं, विशेष रूप से समर्थित फ़ाइल नाम या निर्देशिका में एक तारीख के साथ, जब आप स्रोत नियंत्रण में कुछ डालते हैं, तो यह एक उदाहरण है। मैं डॉन' t आपके लिए कोई शानदार जवाब है, लेकिन मेरा मानना ​​है कि यह असामान्य है। मैं वही लड़ाई लड़ रहा हूं और आपको प्रगति पर तैनात रखूंगा। और, उम्मीद है कि प्रगति होगी और मैं कहीं और देख सकता हूं क्योंकि मैं अराजकता में काम नहीं कर सकता!


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

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

1

हमारे पास विकास कर्मचारियों के 3 सदस्य हैं और स्रोत नियंत्रण का उपयोग करते हैं। मेरी व्यक्तिगत परियोजनाओं पर मेरे पास एक डेवलपर है और मैं स्रोत नियंत्रण का उपयोग करता हूं। यह टीम प्रबंधन के लिए सिर्फ उपयोगी नहीं है, यह उपयोगी है कि बिना किसी डर के आप प्रयोगात्मक कार्य करने में सक्षम हों।

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


1

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

इसे लागू न करने का कोई भी कारण केवल खराब काम का बहाना हो सकता है या ऐसा होने का इंतजार किया जा सकता है।

बस उन्हें बताएं कि इस वर्ष 1 जनवरी को ऐप क्या था, यह पता लगाने के लिए कितना महान है

कैसे इस कार्यक्षमता के बारे में मार्च में जोड़ा गया था मुझे लगता है कि हमें इस पर थोड़ा और विस्तार करने की आवश्यकता है।

वाह यह बग 154256 इस प्रतिबद्ध में तय किया गया है।

मैं एप्लिकेशन को शाखा कर सकता हूं और तैनाती को बाहर भेज सकता हूं कोई समस्या नहीं है जिसे आप काम कर सकते हैं।

यह आगे और आगे बढ़ सकता है ... (बाद में आने वाले अन्य प्रश्नों पर टिप्पणी जोड़ना याद रखें)


1

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


1

संस्करण नियंत्रण का उपयोग नहीं करने का समर्थन करने के कारण काफी सीमित हैं। मैं जो सोच सकता हूं वह सब चीजों का तकनीकी पहलू है।

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

एक संस्करण प्रणाली का उपयोग करने के कई कारण हैं। बहुत कम से कम चीजों को घूमने से रोकें। पैच के साथ काम करें। वर्जनिंग सिस्टम ठीक वही कर सकता है जो आप कहते हैं कि आप करते हैं।

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

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


1

1990 में मेरी पहली गंभीर नौकरी पर मैं अपने विभाग में काम करने वाला एकमात्र डेवलपर था और स्रोत नियंत्रण का उपयोग करना नहीं जानता था।

बहुत बाद में मुझे पता चला, तब से मैंने कभी ऐसा प्रोजेक्ट नहीं देखा जो इसे स्थापित करने वाली पहली चीजों में से एक न बना हो।

मैंने अपना लगभग सारा काम उस नौकरी पर खो दिया क्योंकि मैंने एक फ़ोल्डर को गलत स्तर पर हटा दिया था। सौभाग्य से मैं एक हफ्ते पहले 5 "फ्लॉपी पर एक कॉपी होम लाया था और कुछ ही दिनों में हफ्तों के काम को फिर से बनाने में सक्षम था।

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


1

मैंने इसे बहुत बढ़ा-चढ़ा कर बताया है ... छोटी इंजीनियरिंग / इलेक्ट्रॉनिक कंपनियों में जहां वे बहुत सारे एम्बेडेड सॉफ्टवेयर / हार्डवेयर करते हैं।

इन जगहों पर SCM इलेक्ट्रॉनिक्स इंजीनियरिंग संस्कृति का हिस्सा नहीं है। उनके पास आमतौर पर प्रति प्रोजेक्ट एक इंजीनियर होता है, जिसे बस नवीनतम रिलीज का बैकअप लेना होता है।

इसलिए ब्रांचिंग / मर्जिंग और यहां तक ​​कि शेयरिंग कोड को अपूरणीय माना जाता है। इसके अलावा, ये कंपनियां शायद ISO9000 हैं, इसलिए यह प्रक्रिया, अल्बेट अजीब है, शायद प्रलेखित है।

किसी भी स्थिति में I / अन्य डेवलपर्स ने अभी SCM का व्यक्तिगत रूप से उपयोग करना शुरू कर दिया है।


0

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

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

जीवाश्म, या कुछ अन्य वीसीएस का उपयोग नहीं करने के लिए मैंने सबसे बड़ी वजहें सुनी हैं:

  1. "प्रोग्रामर" के कई स्क्रिप्ट किडिज़ हैं, और समझ नहीं पाएंगे कि इसका उपयोग कैसे करें
  2. जो लोग सीख सकते थे, उन्हें लगता है कि यह उपयोग करने के लिए एक उपद्रव है
  3. ये लोग पुराने गार्ड हैं, जो नेटवर्क फ़ोल्डर्स के साथ सहज हैं, इसलिए सभी को होना चाहिए
  4. किसी के पास इसे सही तरीके से सेट करने का समय नहीं है, या इसका उपयोग करने का तरीका जानें
  5. जबकि सुविधाएँ महान हो सकती हैं, उनमें से कोई भी आवश्यक नहीं है

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

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

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


0

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

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


स्रोत सुरक्षित और एसवीएन का उपयोग करके संस्करण नियंत्रण स्थापित करना आसान था। यहां तक ​​कि सी.वी.एस. (Git को Windows परिवेश में सेट करना और उपयोग करना आसान नहीं है)
टिम

0

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


मैं पूरी तरह सहमत हूँ। गिट इंस्टॉलर अविश्वसनीय रूप से उपयोग करने में आसान है और आप मिनटों में ऊपर और चल रहे हैं। उन्नत कार्य प्रतीक्षा कर सकते हैं, मूल संस्करण नियंत्रण इंतजार नहीं कर सकता। cd topleveldirectory; git init; git add *; git commit -m "initial commit"
डस्टमैचिन

0

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

उदाहरण के लिए हम पीएचपी में लिखे गए एब्ड ग्रेड सोशल नेटवर्क पर काम कर रहे थे और क्लाइंट चाहता था कि यूजर प्रोफाइल को सब्सक्राइब किया जा सके। मूल रूप से कार्यक्षमता को इस तरह से चेक में लपेटा गया था यदि (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {तो कोड निष्पादित करें}

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

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


0

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

आप कुछ जानकारी यहाँ पा सकते हैं: http://www.internetcontact.be/scm/?page_id=358

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.