तृतीय पक्ष ओपन सोर्स लाइब्रेरी में परिवर्तनों के प्रबंधन के लिए सर्वोत्तम अभ्यास?

Question

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

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

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

क्या मुझे लाइब्रेरी को एक विशेष तरीके से नामित करना चाहिए, इसलिए यह स्पष्ट है कि हमने विशेष संशोधन किए हैं (उदाहरण के लिए कॉमन्स-लैंग-2.x-for-my-project.jar)? क्या मुझे सिर्फ पैच दस्तावेज करना चाहिए और एसवीएन स्थान का संदर्भ देना चाहिए और रीडमे में मेलिंग सूची आइटम का लिंक होना चाहिए? ऐसा कोई विकल्प नहीं है जिसे मैं सोच सकता हूं अपग्रेड परिदृश्य में मूर्ख-प्रमाण है।

इसके लिए सबसे अच्छा अभ्यास क्या है?

Answer 1

विक्रेता शाखाएं एसवीएन "लाल पुस्तक" के अध्याय में यह अच्छी तरह से शामिल है। इस अध्याय में उदाहरण के निकट अपनी स्थिति मैच के लिए लगता है:

http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html

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

इस समस्या का समाधान विक्रेता शाखाओं का उपयोग करना है। एक विक्रेता शाखा आपके स्वयं के संस्करण नियंत्रण प्रणाली में एक निर्देशिका वृक्ष है जिसमें किसी तृतीय-पक्ष इकाई या विक्रेता द्वारा प्रदान की गई जानकारी होती है। विक्रेता के डेटा का प्रत्येक संस्करण जिसे आप अपनी परियोजना में अवशोषित करने का निर्णय लेते हैं उसे विक्रेता ड्रॉप कहा जाता है।
...

Answer 2

बर्ट का जवाब है, जो अच्छा जहाँ तक प्रश्न के स्रोत नियंत्रण भाग का संबंध है के अलावा, मैं भी आप कुछ इकाई-परीक्षण कि आपके परिवर्तन को कवर लिखने सुझाव देना चाहेंगे।

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

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