2008-09-26 14 views
13

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

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

उत्तर

7

यह आम तौर पर आपके प्रोजेक्ट और टीम पर निर्भर करता है। निराशावादी लॉकिंग अच्छा है क्योंकि इसे समझना आसान है - एक समय में एक देव, और कोई विलय आवश्यक नहीं है!

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

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

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

1

सॉफ्टवेयर डेवलपर्स हमेशा आशावादी हैं - बस उनके अनुमानित कौशल को देखें!

प्रैक्टिस में हमें लगता है कि संघर्ष दुर्लभ हैं और कभी-कभी संघर्ष विवाद समाधान चरण से अधिक होने के बारे में चिंता करने के लाभ नहीं हैं।

+1

"सॉफ्टवेयर डेवलपर्स हमेशा आशावादी होते हैं - बस उनकी अनुमानित स्किल्स देखें!" - इसे प्यार करना!! – tjjjohnson

14
  1. स्रोत सेफ के साथ खेलें और डेवलपर को दो सप्ताह की छुट्टियों के लिए छोड़ दें। उसमें जोड़ें VSS व्यवस्थापक आसपास नहीं है। अब आपके पास पोस्ट करने के लिए एक फिक्स है लेकिन आप डेवलपर
  2. की वजह से नहीं कर सकते हैं यदि आपके पास एकाधिक सुविधाएं और/या बग फिक्स पर काम किया जा रहा है। कोई फर्क नहीं पड़ता कि आपका कोड कितना छोटा हो गया है, फिर भी आपको केंद्रीय फ़ाइल के लिए विवाद होगा।
+1

मैं पूरी तरह सहमत हूं, स्कॉट। – itsmatt

+0

मैं सहमत हूं, लेकिन SourceSafe का संदर्भ क्यों देता हूं? हमने समवर्ती चेकआउट मोड में कई सालों तक इसका इस्तेमाल किया - कोई समस्या नहीं। (मैं वास्तव में वीएसएस के लिए सभी नफरत को कभी नहीं समझता। मुझे लगता है कि हम भाग्यशाली थे)। –

+1

@ स्टेव: हाँ, आप वीएसएस काम कर सकते हैं। यदि आप इसे करने के लिए पर्याप्त प्रेरित हैं, तो आप ज़िप फ़ाइलों को भी काम कर सकते हैं। वीएसएस संयुक्त क्रैपी विलय, गैर-परमाणु काम करता है, और एक परिवर्तन-सेट सिस्टम जिसमें टैग शामिल हैं और कुछ भी नहीं।काफी जॉगलिंग चेन आरी नहीं, लेकिन काफी खतरनाक है। – Shog9

2

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

मैंने लॉकिंग के बिना 2 से 6 लोगों की टीमों में काम किया है और हमें कुछ सामान्य और आवश्यक विलय से परे कोई समस्या नहीं थी।

मैंने एक बार Visual SourceSafe होस्टेड प्रोजेक्ट में लॉक करने के साथ भी काम किया। यह आईएमएचओ काउंटर-उत्पादक था।

4
  • तुम हमेशा विकल्प नहीं है करने के लिए को तोड़ने के अलावा
    • कॉन्फ़िग फ़ाइलें
    • XML फ़ाइलें फ़ाइलें
  • यहां तक ​​कि अपेक्षाकृत छोटे फ़ाइलों को अभी भी अलग-अलग भागों शामिल कर सकते हैं कि एक से अधिक डेवलपर को
    • लाइब्रेरी
    • तक पहुंच की आवश्यकता है "गलती"
    की जाँच की
  • उपयोगिताएँ
  • उपकरण विलय फ़ाइलों होने डेवलपर्स की वजह से ज्यादा होशियार, उससे कहीं अधिक किया गया है
    • संघर्ष नहीं बल्कि दुर्लभ
  • कम कर देता है देरी कर रहे हैं
  • 3

    यदि कोई डेवलपर विलय और विवादों को ठीक करने में संभाल नहीं सकता है, तो उसे फिर से शिक्षित किया जाना चाहिए।

    छोटी फ़ाइलों के लिए संघर्ष करना आम बात है, उदाहरण के लिए जेएसपी के साथ एक व्यक्ति (वेब ​​डेवलपर) लेआउट कोड बदल सकता है, और कोई और जेएसपी मॉडल के मॉडल के लिए एपीआई बदल सकता है।

    6
    1. बॉब FooBar.java
    2. जॉन संपादन
    3. बॉब अपने स्थानीय प्रतिलिपि संपादित करता है वैसे भी के लिए बाहर की जाँच की है और FooBar.java.bak
    4. रूप में सहेजता है जब जॉन ने अपने में जाँच करता है संपादित करने के लिए की जरूरत है, बॉब यह और यह जाँच करता है
    5. जॉन हो जाता है में से अधिक इसे बाहर की जाँच करता है
    6. बॉब प्रतियां FooBar.java.bak उनकी पहली फीचर reimplement को

    मैंने देखा है कि यह समय और समय फिर से होता है। डेवलपर्स ऐसा करते हैं क्योंकि इस प्रक्रिया से परेशान है:

    1. बॉब FooBar.java
    2. जॉन संपादन
    3. बॉब अपने अंगूठे twiddling प्रतीक्षा करने के लिए जब तक जॉन किया जाता है है के लिए बाहर की जाँच की है संपादित करने के लिए की जरूरत है

    निराशावादी लॉकिंग शौकिया घंटे की तरह लगता है, क्षमा करें।

    +0

    बॉब एक ​​सैंडबॉक्स प्रतिमान का उपयोग करते समय विलय नहीं करने के लिए एक असली झटका है। जॉन स्रोत नियंत्रण से अपने पहले संस्करण को पुनः प्राप्त करने और बॉब के साथ अपने परिवर्तनों को विलय करने के लिए एक असली डमी नहीं है। – indiv

    1

    यदि आपका कोड फ़ाइलों इतना बड़ा आप लगातार एक से अधिक व्यक्ति एक ही समय

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

    दूसरे शब्दों में आपको पता चलेगा कि 'बॉब' घटक एक्स/वाई/जेड में बदलावों का एक बड़ा सेट कर रहा है, यदि आपके पास घटक एक्स में एक बग फिक्स है तो आप सबमिट करने से पहले बॉब से बात करना सीखेंगे आपके परिवर्तन

    मैं कहता हूँ के रूप में यह आदर्श है;)

    1

    निराशावादी ताला एक अच्छा विचार है, तो गंभीर संघर्ष होने की संभावना होने जा रहे हैं है। अधिकांश प्रोग्रामिंग के लिए आपको कोई गंभीर संघर्ष नहीं दिखाई देगा, इसलिए निराशावादी लॉकिंग काफी व्यर्थ है। इसके लिए अपवाद होंगे यदि आप हैं:

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

    अन्यथा ...

    3

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

    असली मुद्दा यह तय करना है कि क्या आपकी शेष राशि

    के बीच मर्ज गलतियों बनाम की संभावना असुविधा लोगों की वजह से ताला लगा फ़ाइलों

    धारणा है कि या तो एक ताला या गैर लॉकिंग सिस्टम "बेहतर है "बकवास है।

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

    मेरा मुद्दा यह है कि यह एक समझदार बहस नहीं है। सिस्टम की सफलता नीचे आती है जब आप होते हैं तो संघर्ष बिंदुओं का प्रबंधन कैसे करते हैं, न कि एक सिस्टम या दूसरा बेहतर है।

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