पर्सफोर्स देव शाखाएं - स्पैस ब्रांचिंग बनाम निजी शाखा

Question

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

अन्य विधि जो मैंने सुना है स्पैर्स ब्रांचिंग है। यह Practical Perforce (अध्याय 9, पृष्ठ 242) में वर्णित है। यह एक शाखा बनाता है, लेकिन केवल उन फ़ाइलों के साथ जिन्हें आपको संपादित करने की आवश्यकता होगी। फिर आप इस स्पैस देव शाखा क्लाइंट व्यू के साथ लक्षित शाखा क्लाइंट व्यू को ओवरलैप करते हैं।

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

एकीकरण भी बलफोर्स को फ़ाइलों की "आलसी प्रतिलिपि" करने में सक्षम बनाता है। जब आप फ़ाइलों को ब्रांच करते हैं, तो सर्वर वास्तव में फ़ाइलों की दो प्रतियां नहीं रखता है - यह केवल स्रोत फ़ाइल रखता है और डेटाबेस में एक पॉइंटर इस तथ्य को रिकॉर्ड करता है कि लक्ष्य फ़ाइल में शाखा हुई है। आलसी प्रतियां कम ओवरहेड ऑपरेशन की शाखा बनाते हैं; सर्वर को फ़ाइलों की डुप्लिकेट प्रतियों का ट्रैक रखने की आवश्यकता नहीं है।

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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