अमानक तोड़फोड़ आयात Git को

Question

हम एक गैर मानक तोड़फोड़ respository कि हम Git कन्वर्ट करने के लिए करना चाहते हैं संभाल करने के लिए कैसे। समस्या यह है कि मुझे यह सुनिश्चित करने के लिए वास्तव में कहां से शुरू करना है कि हम पूरा इतिहास नहीं रखते हैं लेकिन पूरी गड़बड़ी के साथ खत्म नहीं होते हैं।

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

-- plugin1 
    - trunk 
    - branches 
    - tags 
-- pluginX 
    - trunk 
    - branches 
    - tags 
-- trunk (core platform) 
    - <various sub dirs) 
-- branches (various feature branches of the entire repository) 
    - refactoring1 
    - refactoringX 
-- tags (various tags of customer releases of full respository) 
    - customerX_1.x 
-- vendor (vendor drops and tracking of 3rd party source deps) 
    - 3rd_party_code_A 
    - 3rd_party_code_X 

समय के साथ हम एक जोड़े को जोड़ा अधिक निर्देशिकाओं सहित जड़ हैं:

-- releases (replaced tags; branches for released stable versions of repos) 
-- sandbox (area for misc projects of interest; should have been new repo) 

फिर हम इस साफ और साथ समाप्त हो गया

साल के पहले जोड़े की तरह संरचित किया गया था:

-- trunk 
    - platform 
    - plugin1 
    - pluginX 
-- stable (stable release branches of trunk) 
    - 1.1 
    - 1.2 
-- tags (release points; marks a point on a stable branch) 
    - 1.1.1 
    - 1.1.2 
-- vendor 
-- sandbox 
-- releases (copies of old releases of interest) 

तो यह हमारा इतिहास है। हम क्या खत्म करना चाहते हैं उम्मीद है कि बहुत साफ है। फिलहाल हम इस तरह दिखने वाले गिट रिपोजिटरी के आधार के बारे में सोच रहे हैं (मूल रूप से पिछले 'ट्रंक' निर्देशिका की एक प्रति)।

- platform 
- plugin1 
- pluginX 

Branches: 
    - stable/1.1 
    - stable/1.2 
Tags: 
    - rel/1.1.1 
    - rel/1.1.2 

हम सैंडबॉक्स और विक्रेता को अपने स्वयं के भंडार में रखना चाहते हैं। (यह सुनिश्चित नहीं है कि यह कैसे करें, लेकिन हो सकता है कि केवल एक एसवीएन रिपोजिटरी का सबसेट आयात करने का कोई तरीका हो)

शाखाओं और टैग तक, हम चाहते हैं कि कोड 'स्थिर' से शाखाओं के रूप में समाप्त हो जाए, टैग के रूप में 'टैग' से कोड को स्थिर में टैग के रूप में समाप्त करने के लिए।

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

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

किसी को भी यह कैसे आयात आवश्यक कार्रवाई की अनुशंसाओं है?

उदाहरण के लिए:

• यह पुनर्गठन भर में पूरा इतिहास रखने के लिए संभव है?
• क्या हमें किसी भी तरह से आयात से पहले इसे साफ करने के लिए सबवर्सन रिपोजिटरी को फिर से लिखना चाहिए और यदि ऐसा है तो कैसे?
• क्या हमें पूरा इतिहास आयात करना चाहिए और फिर इसे गिट में पुन: व्यवस्थित करना चाहिए और ऐसा कैसे?
• इस आयात को साफ करने के तरीके के बारे में कोई विचार?

Answer 1

आपकी स्थिति के आधार पर, गिट-एसवीएन (डिफ़ॉल्ट --follow-parent विकल्प के साथ) बस चाल चल सकता है। सबसे पहले आपको जो करना चाहिए वह कुछ गिट-एसवीएन रनों का प्रयास करें, -T, -b, और -t विकल्प निर्देशिका संरचना के साथ मदद करने के लिए ध्यान से वर्तनी करें।

हालांकि, आप एक जटिल निर्देशिका संरचना इतिहास के साथ परेशानी में भाग सकते हैं।

मैं हाल ही में एक बहुत ही समान स्थिति में था, जो मेरी कंपनी के सबवर्जन कोड को गिट करने के लिए माइग्रेट कर रहा था, जहां एसवीएन इतिहास आप जो वर्णन कर रहे हैं उसके समान पुनर्गठन के माध्यम से चला गया था। मेरे मामले में, मैं परियोजनाओं को एक सबवर्जन रिपोजिटरी से कई गिट रिपॉजिटरीज़ (प्रति परियोजना एक) में अलग करना चाहता था।

मैं निर्णय लेने में आसान तरीका ले रहा था, यह निर्णय लेना कि इतिहास के कुछ महीनों से अधिक माइग्रेट करना महत्वपूर्ण नहीं था, इसलिए प्रत्येक प्रोजेक्ट के लिए मैंने निर्धारित किया कि सबसे पुराना संशोधन क्या था कि गिट-एसवीएन सुन्दर तरीके से संभाल सकता है, और फिर केवल वहां से शुरू होने वाला इतिहास प्राप्त हुआ (git-svn -r का उपयोग करके)। पिछले वीसीएस माइग्रेशन (वीएसएस से एसवीएन, 2005) को संभालने के बाद, मुझे अनुभव से पता था कि दीर्घकालिक इतिहास का शायद ही कभी उल्लेख किया जाता है। किसी भी मामले में, पुराना सबवर्जन सर्वर चलाना आसान है (केवल पढ़ने के लिए मोड में), ताकि यदि आवश्यक हो तो चीजों को देखने के लिए इसका उपयोग किया जा सकता है।

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

सामान्य तौर पर, सफाई और पूर्णता इतिहास के जब इस तरह का माइग्रेशन करने दो परस्पर विरोधी लक्ष्यों रहे हैं। सौभाग्य से, वे दोनों वास्तव में अतिरंजित हैं - वे दोनों व्यावहारिक आवश्यकताओं के मुकाबले सौंदर्यशास्त्र की भावना से अपील करते हैं।

संपादित करें: स्वच्छता के लिए साइड टिप: आयातित शाखाओं को एक अद्वितीय उपसर्ग देने के लिए --prefix विकल्प का उपयोग करें, क्योंकि यह संभावना है कि आपके पास गिट में अलग-अलग ब्रांचिंग सम्मेलन होंगे, और यह देखना आसान बनाता है बाद में svn इतिहास।