🚵 🌲 🛠️ एक पेड़ में एक विरासत कहानी डालना: इष्टतम शाखा बिंदु खोजना 🚐 🚣 🙍🏻

मेरी सेवा के परिणामस्वरूप, मुझे ~ 15 साल के इतिहास और विभिन्न संगठनों में कई दर्जन प्रतिष्ठानों के साथ एक निश्चित प्रणाली विरासत में मिली। सिस्टम स्वयं अपेक्षाकृत छोटा है (कोड की ~ 25K लाइनें, ~ 1K कमिट), लेकिन समस्या रिलीज प्रबंधन में थी:

तोड़फोड़ में एक मुख्य पेड़ था (शुरू में cvs में, निश्चित रूप से), जहां "पार्टी का मुख्य पाठ्यक्रम" आयोजित किया गया था - कुछ बड़े पैमाने पर बदलाव किए गए थे, नई सुविधाओं को जोड़ा गया था, वैश्विक त्रुटियां तय की गई थीं, आदि।
द्वारा विशिष्ट स्थापनाएं की गईं:
- सबसे अच्छा, svn चेकआउट, जिसे तब svn अपडेट के माध्यम से अपडेट किया गया था; लगभग सभी प्रतिष्ठानों में स्थानीय सुधार "लाइव" किए गए थे (कम से कम कॉन्फ़िगरेशन फ़ाइलों को ठीक किया गया था) और ये परिवर्तन कहीं भी प्रतिबद्ध नहीं थे; अगर अगले svn अपडाउन के दौरान अपस्ट्रीम में बदलावों ने टकराव पैदा कर दिया - प्रोग्रामर द्वारा "विरोधाभास" को हल किया गया, जिसने अपडेट किया, फिर से, बिना किसी ट्रैकिंग परिवर्तन के
- सबसे खराब स्थिति में, svn निर्यात, जो तब, निश्चित रूप से, अद्यतन नहीं किया गया था, शेष एक बार और सभी के लिए (या कम से कम जब तक अधिकारियों ने अपने मन को नहीं बदला) निर्यात की तारीख के विकास के स्तर पर; विशेष रूप से उपेक्षित मामलों में (1990 के दशक के उत्तरार्ध से - 2000 के दशक के प्रारंभ में), ऐसा इसलिए भी किया गया क्योंकि बस एक चेकआउट करने का कोई भौतिक अवसर नहीं था - संगठन के पास इंटरनेट का उपयोग नहीं था, संग्रह को केवल एक डिस्केट पर लाया गया था और एक बार जगह पर तैनात किया गया था

व्यवहार में, निश्चित रूप से, इस प्रणाली के आभारी ग्राहक समय-समय पर अभी भी समर्थन प्राप्त करना चाहते हैं, बग फिक्स, और यहां तक कि कभी-कभी सिस्टम कोर में कुछ वैश्विक सुधार भी।

एक छोटे से परामर्श के बाद, svn में इस तरह की वितरित प्रणाली का समर्थन जारी रखने के लिए अनुचित माना जाता था और इसे git में स्थानांतरित करने का निर्णय लिया गया था।

समस्या संख्या एक - मास्टर पेड़ को svn से git तक खींचना - आमतौर पर git-svn के मानक साधनों से तय किया गया था।

समस्याओं का सेट नंबर दो - इस पेड़ में विभिन्न प्रतिष्ठानों में कई कांटे कैसे डालना है - यह "जैसा कि वे आते हैं" को अलग करने का निर्णय लिया गया था। जब अगला संगठन जाग गया, तो यह आवश्यक था:

उन्हें कांटा
यह समझें कि एक समय में वह कहाँ खो गया था और अंतिम बार किस स्तर तक स्थानांतरित किया गया था (यदि यह svn चेकआउट है)
इस कांटे के लिए एक नया ब्रंच बनाएं
अधिक या कम शब्दार्थ से संबंधित छोटे टुकड़ों में किए गए परिवर्तनों को विभाजित करने और उन सभी को इस ब्रंच के लिए प्रतिबद्ध करने का प्रयास करें

मुख्य प्लग अचानक चरण 2 पर दिखाई दिया - यह समझने के लिए कि अगली स्थापना कहां से जाली थी। Svn चेकआउट के मामले में, आप कम से कम कामकाजी प्रतिलिपि की वर्तमान स्थिति को देख सकते हैं, जबकि svn निर्यात के मामले में, अनुमान लगाया गया था कि यह अप्रभावी है। एक दो बार कोड की स्थिति के अर्ध-हाथ वाले पुरातात्विक अध्ययन पर ठोकर खाई, मैं थक गया और खोजों को स्वचालित करने का फैसला किया। कोई तैयार समाधान नहीं था (git bisect है, दुर्भाग्य से, यहाँ उपयुक्त नहीं है) और निम्नलिखित स्क्रिप्ट निकली:

#!/bin/sh -ef if [ $# -ne 2 ]; then echo "Usage: $0 <git-repo-dir> <candidate-checkout-dir>" exit 1 fi GIT_REPO="$1" CANDIDATE_DIR=$(cd "$2" && pwd) TAB=$(printf '\t') cd "$GIT_REPO" COMMITS=$(git log --all --format=format:%H) # Remember current commit CURRENT_COMMIT=$(git rev-parse HEAD) for C in $COMMITS; do git checkout --quiet $C echo -n "$C$TAB" diff -urN --exclude=.git --exclude=.svn "$CANDIDATE_DIR" . | wc -l done | sort -t"$TAB" -k2,2n # Restore current commit git checkout --quiet "$CURRENT_COMMIT"

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

 3810315aaa238e32a7106312f9973f1d1f0ea097 651
 19b595d87eecc43933ea60d89882319c7ac3f512 835
 989cee69664733b773a4a81cc49e2a1a0cdff38a 872
 9026dae1154f98018c808b73c7f1c6cd09310dc7 885
 802943edf287ad28d5e71a57510400afacb49176 894
 c5bd4050fce754e16664e6e1eeb57a4ff3ed06c6444
 dcb70c4a2e9fc0431ceb6154ecd1688189362622 908
 ...

इसका मतलब यह है कि सबसे अधिक संभावना है कि समस्या किसी तरह हल हो जाएगी:

 $ git branch new-organization 3810315aaa238e32a7106312f9973f1d1f0ea097 $ git checkout new-organization $ cp -r ../new-organization-fork/* .

... जिसके बाद आप पहले से ही परिवर्तनों से निपट सकते हैं, उन्हें भागों में विभाजित करने की कोशिश करें और प्रतिबद्ध करें (शायद - साथ-साथ और - यदि आप उन्हें समझ सकते हैं)।

मुझे खुशी होगी अगर उपरोक्त समाधान किसी और के लिए उपयोगी है। टिप्पणी और बेहतर करने के लिए सुझावों का स्वागत है।

एक पेड़ में एक विरासत कहानी डालना: इष्टतम शाखा बिंदु खोजना

More articles: