एसवीएन क्या नहीं कर सकता

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



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





हमने प्लेटफ़ॉर्म की मुख्य शाखा ली, इसे 5 शाखाओं से मॉड्यूलर शाखाओं में विभाजित किया, जिनमें से प्रत्येक में हमने एक अलग मॉड्यूल की कार्यक्षमता को जोड़ा और ट्रंक से उनमें परिवर्तन करके उनकी प्रासंगिकता बनाए रखी।



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



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



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



तो, हमारे मामले में एसवीएन में मिश्रण तंत्र के कार्यान्वयन की मुख्य विशेषता यह है कि किसी भी परिवर्तन के किसी भी हस्तांतरण के साथ, यहां तक ​​कि एक शाखा से दूसरे में कुछ छोटे संपादन, इस संपादन के साथ, सभी मर्ज इतिहास भी पूरी तरह से स्थानांतरित हो जाते हैं।



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



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



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



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



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



उदाहरण के लिए, SVN, दोनों को ब्लॉक करता है।











UP: tzlom का कहना है कि Git आपको दोनों संपादन करने की अनुमति देगा, और स्वाभाविक रूप से, 9 वीं में एक टकराव पैदा करेगा। सामान्य तौर पर, एसवीएन में आप तालों को अनदेखा भी कर सकते हैं, और फिर प्रभाव समान होगा।



यूपी: PQR ने सुझाव दिया कि मर्क्यूरियल एडिट्स को ट्रांसप्लांट एक्सटेंशन का उपयोग करके एटिट्यूड ट्रांसफर किया जा सकता है, और चैरी-पिक कमांड का उपयोग करके गिट में, लेकिन, जाहिर है, दोनों मामलों (8 और 9) में दोनों एडिट की अनुमति होगी।