स्रोत नियंत्रण के लिए कदम बना रही है


10

हमारा एक काफी छोटी कंपनी (3-4 प्रोग्रामर और 3-4 साइट डिज़ाइनर) है, जो एक एकल-उद्देश्य PHP वेब ऐप विकसित करता है जो लगभग 100+ वेबसाइटों को कार्यक्षमता प्रदान करता है। हमने एक अलग विकास और उत्पादन वातावरण में कुछ वर्षों तक काम किया है, जिसने काफी अच्छा काम किया है। हमेशा विकसित होने के लिए पर्याप्त पृथक विशेषताएं होती हैं जो प्रोग्रामर वास्तव में कभी नहीं टकराते हैं और स्रोत नियंत्रण के बिना काम करना अधिक सुविधाजनक था; भले ही इसमें डेटा हानि का जोखिम था और हमारे पास अनजानी चाल में गायब होने वाली फाइलों का हमारा उचित हिस्सा था।

अन्य विचार यह है कि हमारे डिजाइनर तकनीक प्रेमी नहीं हैं (मैंने WYSIWYGs का उपयोग करने के बजाय उन्हें html मार्कअप में पेश किया है)। यह एक कारण रहा है कि वर्जनिंग में कदम रखने में संकोच।

हालाँकि, अब जब हम 100+ साइटों पर पहुँच चुके हैं और विकास दल बढ़ रहा है, तो हम अपनी प्रक्रियाओं को मानकीकृत करने की कोशिश कर रहे हैं और जहाँ तक प्रोग्रामर जाते हैं, स्रोत-नियंत्रण एक तार्किक कदम लगता है। मुझे उम्मीद है कि इससे हमारी पैच तैनाती में भी तेजी आएगी।

दुर्भाग्य से, मैंने एक स्रोत-नियंत्रण प्रणाली स्थापित करने के साथ बहुत सीमित अनुभव किया है। मैं एक समान सेटअप वाले लोगों के बारे में सुनने के लिए उत्सुक हूं, या स्विच बनाने का अनुभव कर रहा हूं:

1) क्या आप सब कुछ संस्करण (साइटें, सीएसएस, एचटीएमएल टेम्प्लेट, और ऐप कोड) और इस तरह डिजाइनरों को संस्करण सीखने के लिए मजबूर करते हैं? या यह सिर्फ डेवलपर्स है कि आवेदन कोड पर काम करते हैं?

2) शुरू में स्रोत नियंत्रण स्थापित करने के लिए बाहर देखने के लिए कुछ नुकसान क्या हैं?

3) स्रोत नियंत्रण के लिए देव => उत्पादन युक्तियों की तैनाती।

सभी जानकारी के लिए धन्यवाद।

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

संपादन 2: बहुत सारे अच्छे उत्तर, और हम विभिन्न संस्करण नियंत्रण प्रणालियों में देख रहे हैं। जवाब देने के लिए सभी का शुक्रिया!


@mattdm आह, 'संस्करण-नियंत्रण' ... मैं 'स्रोत-नियंत्रण' / आह की कोशिश कर रहा था
2

इसके अलावा "संशोधन नियंत्रण"।
Mattdm

Adobe और अन्य सबसे बड़े ग्राफिक्स सॉफ्टवेयर डेवलपर्स के पास पहले से ही परिसंपत्ति संस्करण नियंत्रण के अपने कार्यान्वयन हैं - यह दर्शाता है कि यह वास्तव में डिजाइनरों के imho के लिए और भी अधिक वांछनीय होना चाहिए (और हां जिसमें संस्करण संपत्तियां शामिल हैं और न केवल पाठ विवरणक फाइलें)।
ऑस्कर ड्यूवॉर्न

जवाबों:


10

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

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

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


उत्तर के लिए धन्यवाद, Mattdm। मैं उन लिंक की जाँच करूँगा
डीटीएच

स्पोलस्की लेख के लिए उस सूचक के लिए +1; मैं सिर्फ उसका Hg ट्यूटोरियल (HgInit) पढ़ रहा हूं और मुझे लगता है कि मैं dVCS लेना शुरू कर रहा हूं, पहली बार। धन्यवाद (आप और जोएल)।
MadHatter

3

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

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

उत्पादन के लिए देव आसान है, हर बड़े मील के पत्थर पर एक शाखा बनाते हैं। संस्करण नियंत्रण प्रणाली में निर्देशिका लेआउट आमतौर पर कुछ इस तरह दिखता है:

/ ट्रंक / परियोजना / शाखा / परियोजना / संस्करण 1 / शाखा / परियोजना / संस्करण २ / शाखा / परियोजना / संस्करण ३

तो मान लें कि आपको उत्पाद के संस्करण 2 में एक बग मिल गया है, आप उस शाखा पर नेविगेट करते हैं, इसे ठीक करते हैं, और संस्करण 2.1 जारी करते हैं। जब आप नए संस्करण 4 के लिए / ट्रंक / प्रोजेक्ट फ़ोल्डर पर काम कर रहे हों, तो यह आपके लिए है कि कौन सी सुविधाएँ पीछे और आगे की तरफ मर्ज की गई हैं।

एससीएम कूल-सहायता पीने वालों को आपको मूर्ख मत बनने दो, वहाँ लोकप्रिय संस्करण नियंत्रण प्रणालियों के बीच बहुत कम कार्यात्मक अंतर हैं, जैसे कि तोड़फोड़ और गिट। आपकी टीम के लिए सबसे महत्वपूर्ण बात यह होगी कि वे सर्वर आपके मौजूदा टूल के साथ कितनी अच्छी तरह से एकीकृत होंगे। मुझे WYSIWYGs पसंद नहीं है, लेकिन यह सुनिश्चित करना अच्छा है कि ग्रहण-php या अन्य IDEs जो सर्वर के साथ संगत हैं।


अरे यार, तुम्हें कुछ बेहतर कूल-एड चाहिए। आप सीवीएस या एसवीएन प्रणाली की तरह कुछ को दोहराने के लिए वितरित संस्करण नियंत्रण का उपयोग कर सकते हैं, लेकिन वास्तव में एक मौलिक अंतर है। (यह एसवीएन पर दस्तक देने के लिए नहीं है, जो इसके लिए ठीक है, आपके मन में है।)
मैट्टम

3

मैं एक डेवलपर हूं और इससे पहले एक आईटी व्यवस्थापक के रूप में काम करने में शामिल रहा हूं।

अपने विशिष्ट प्रश्नों के उत्तर देने के लिए:

1) हाँ, संस्करण सब कुछ।

2) सुझाव दें कि आप लोगों को सीखने के लिए एक डमी संस्करण नियंत्रण रिपॉजिटरी और डमी प्रोजेक्ट स्थापित करते हैं।

3) उन संस्करणों को टैग करें जो उत्पादन में डालते हैं। यहां तक ​​कि परीक्षण। फिर आप हमेशा एक विशिष्ट संस्करण देख सकते हैं कि कोई व्यक्ति चल रहा है।

मुझे लगता है कि आपने सीवीएस प्रश्न को टैग कर दिया है।

मेरा सुझाव है कि इसके बजाय तोड़फोड़ पर एक गंभीर नज़र डालें, जो कछुआ एसवीएन के साथ संयुक्त है जो इसे उपयोग करना बहुत आसान बनाता है। साथ ही एक TortoiseCVS भी है।

मेरा सुझाव है कि आप संस्करण नियंत्रण पर एक इन-हाउस ट्यूटोरियल चलाते हैं। मुझे आश्चर्य होगा अगर आपके डेवलपर्स / डिजाइनरों ने इससे पहले सामना नहीं किया है। कछुआ बस इसे बहुत उपयोगकर्ता के अनुकूल बनाता है।

यह एक वेब इंटरफेस को cv या तोड़फोड़ में स्थापित करने के लिए भी फायदेमंद हो सकता है।

सीवीएस पर तोड़फोड़ करने का कारण यह है कि सीवीएस बहुत अच्छा है, इसमें कुछ गंभीर डिजाइन और कार्यान्वयन समस्याएं हैं। मेरे लिए बड़ी बात यह थी: 1) आप निर्देशिकाओं को 2 संस्करण नहीं कर सकते हैं) बाइनरी फ़ाइल हैंडलिंग बहुत अच्छी नहीं है क्योंकि बहुत सी चीजें पाठ के लिए डिफ़ॉल्ट हैं। 3) कोई परमाणु नहीं करता है। 4) मुझे याद है कि यह अक्सर गड़बड़ होता है और चारों ओर से लॉक फ़ाइलों को छोड़ना पड़ता है, जिन्हें मुझे कोड स्टोर से मैन्युअल रूप से निकालना पड़ता था। आपकी rm लॉक फ़ाइलों के बाद से ऐसा करने में भ्रष्टाचार के लिए जगह थी। 5) एसएसएल यूजर्स / पासवर्ड को सपोर्ट और मैनेज करता है

तोड़फोड़ मूल रूप से उन सभी समस्याओं को ठीक करता है जो संभवतः कई अन्य हैं। इसमें एक्सटर्नल (जो मैं वास्तव में उपयोग करता हूं) जैसी कई उन्नत सुविधाएँ हैं। और यह संभवतः उपयोगकर्ताओं / समूहों को सक्रिय निर्देशिका में जोड़ने के लिए है जो आपको उपयोगी मिल सकते हैं। उस समय मैंने CVS का उपयोग किया था जो उपलब्ध नहीं था। यह अब हो सकता है, मैंने जाँच नहीं की है।

संभवतः svn के आसपास अपना सिर पाने के लिए सबसे बड़ा अंतर इसका उपयोग करने में है कि आप टैग नहीं बनाते हैं। इसके बजाय आप बनाते हैं कि क्या प्रतियाँ दिखाई देती हैं जहाँ प्रोजेक्ट डायरेक्टरी को टैग फ़ोल्डर में कॉपी किया जाता है और एक नाम दिया जाता है। प्रलेखन में एक नज़र है और आप देखेंगे कि मेरा क्या मतलब है। मुझे पता है कि यह अजीब है लेकिन आपको इसकी आदत है।

यह वेबसाइट कुछ लाभ की हो सकती है (हालाँकि मैं इसके लिए वाउच नहीं कर सकता): php वेबसाइटों के लिए एक मॉड्यूलर svn रिपॉजिटरी की स्थापना http://www.howtoforge.com/set-up-a-modular-svn-repository-for -php-वेबसाइटों


हाँ, मैंने केवल cv के रूप में टैग किया क्योंकि मुझे सही टैग नहीं मिला (जो कि 'संस्करण-नियंत्रण' के रूप में निकला) मैंने svn के साथ थोड़ा अतीत में खेला है और संभवत: इससे पहले git और कुछ अन्य लोगों की जांच करूंगा। अंतिम निर्णय लेना। सुझावों के लिए भी धन्यवाद, विशेष रूप से डमी संस्करण के बारे में। यह लिंक मददगार होगा क्योंकि मुझे यकीन है कि मेरे सवालों में से एक होगा जब मैं अंत में संस्करण-नियंत्रण स्थापित
करूंगा

3

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

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

यदि अधिकांश आउटेज एप्लिकेशन कोड के कारण होते हैं, तो उसे नियंत्रित करके शुरू करें; यदि अधिकांश सीएसएस पैच से अनियोजित है, तो उसे नियंत्रित करें; और इसी तरह।

न केवल यह आपको निवेश के समय के लिए सबसे अच्छा रिटर्न देगा, बल्कि यह आपको भविष्य में संस्करण नियंत्रण के उपयोग को बढ़ाने के लिए ध्वनि कारण भी देता है: "जब से हमने एप्लिकेशन कोड में संस्करण नियंत्रण जोड़ा, 30 मिनट में अनियोजित आउटेज 11 से एक महीने के लिए गिरा दिया है 2. उन दो स्थिर HTML परिवर्तन के कारण थे, इसलिए हम उन अगले संस्करण को नियंत्रित करने का इरादा रखते हैं। "

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

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


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

अरे, मैं भी; बिट पढ़ें जो कहता है कि "मैं सहमत हूं कि सबसे अच्छा अभ्यास संस्करण-सब कुछ नियंत्रित करना है"। लेकिन 1 संपादन में ओपी विशेष रूप से सबसे अच्छी एक के लिए वैकल्पिक रणनीतियों के लिए पूछता है, और यह बहुत अधिक दूसरा सबसे अच्छा है, afaict।
MadHatter

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

यह वास्तव में एक व्यवहार्य विकल्प है। विशेष रूप से एक कंपनी की मानसिकता के साथ 'इसे साबित करने से पहले हम इसे पूरी तरह से प्रतिबद्ध हैं'।
डीटीएच

2

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

नुकसान: मैं व्यक्तिगत रूप से संस्करण नियंत्रण के अपने सीमित रूप से सीमित उपयोग के दौरान किसी भी तरह से नहीं आया हूं।

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

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

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


2

सब कुछ संस्करण।

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

यदि आप "ग्राहक की साइट में सीधे चेकआउट" वितरण मॉडल के साथ जाते हैं, तो आप यह सुनिश्चित करना चाहेंगे कि आपका सर्वर संस्करण नियंत्रण निर्देशिकाओं तक पहुंच को बाहर कर दे ताकि लोग http://example.com/ पर ब्राउज़ न कर सकें । git / और अपने इंटर्ल्स में झाँकें। इसके अलावा, मैं निश्चित रूप से प्रत्येक ग्राहक के लिए एक परीक्षण और उत्पादन virtualhost होगा ताकि यह सुनिश्चित किया जा सके कि साइट अपडेट haywire नहीं है। विशेष रूप से यदि आप अलग-अलग ग्राहकों की फ़ाइलों में कस्टम परिवर्तन कर रहे हैं, तो परिवर्तनों को लाइव करने से पहले आपको संघर्षों को संभालने की आवश्यकता होगी। इस मामले में आप परीक्षण वर्चुअल होस्ट को चेकआउट / अपडेट करेंगे, और जब सब कुछ सही होगा, तो आप परीक्षण वर्चुअल होस्ट को उत्पादन वर्चुअल होस्ट पर कॉपी करेंगे।


दुर्भाग्य से, यह अनुकूलन की संभावना के लिए अनुमति देने के लिए प्रत्येक साइट को 'कस्टम' के साथ स्थापित करने जा रहा है (भले ही इस समय कोई भी मौजूद नहीं है)
डीटीएस

@Dest यह अभी भी किया जा सकता है, यह सिर्फ अधिक संघर्ष के लिए अधिक काम का मतलब है, अनुकूलन की प्रकृति पर निर्भर करता है। बेशक, यदि आप बहुत सारे अनुकूलन कर रहे हैं, तो संघर्षों से निपटने के लिए यह भूलना बेहतर हो सकता है कि आपने एक ग्राहक के लिए index.php को बदल दिया है और इसे एक नए index.php के साथ बदल दिया है जिसमें विशेष सुविधाएँ नहीं हैं
डर्फ़

@ इस परीक्षण में, मैं इस मामले के लिए "वितरित संस्करण नियंत्रण" सुझावों को द्वितीय दूंगा। आप वास्तव में ग्राहक के लिए आपके द्वारा किए गए कस्टम परिवर्तनों को ट्रैक कर पाएंगे और उन्हें ग्राहक के "व्यक्तिगत" रिपॉजिटरी में चेक कर सकते हैं, फिर "केंद्रीय" रिपॉजिटरी से परिवर्तनों को खींच सकते हैं (बस क्लाइंट के कस्टम परिवर्तनों को कभी भी पीछे से न धकेलें एक ग्राहक केंद्रीय भंडार के लिए)
DerfK

0

सभी लोग जो संस्करण के बारे में कह रहे हैं वह अच्छा है।

यदि आप तोड़फोड़ के साथ जाने का निर्णय लेते हैं, तो क्या मैं बिटनामी ट्राक स्टैक की कोशिश कर सकता हूं; http://bitnami.org/stack/trac

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

अपने सभी विंडोज डेवलपर्स को TortoiseSVN दें। सभी को कुछ svn कमांड लाइन की मूल बातें सिखाएं।

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

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