स्रोत नियंत्रण के तहत कोड द्वारा उपयोग किए गए तृतीय पक्ष स्रोतों और बाइनरी का प्रबंधन

Question

मेरे पास स्रोत नियंत्रण के तहत एक बड़ा कोड आधार है (उपversण, अब गिट था)। कोड संकलित करने और परीक्षण चलाने के लिए मैं तृतीय पक्ष पुस्तकालयों का एक सेट उपयोग करता हूं। इन पुस्तकालयों

• बाइनरी केवल
• 3 पार्टी सूत्रों
• 3 पार्टी सूत्रों का कहना है + स्थानीय संशोधन

कुछ categoriesL में बांटा जा सकता प्रत्येक लायब्रेरी उसका {विंडोज, लिनक्स} X {डिबग है, रिलीज} एक्स {32 बिट, 64 बिट} विन्यास। इसके अलावा ये पुस्तकालय मेरे प्रोजेक्ट के समय और विभिन्न संस्करणों के साथ विकसित होते हैं, इन पुस्तकालयों के विभिन्न संस्करण/निर्माण का उपयोग करते हैं।

मेरा प्रश्न यह है कि इन तृतीय पक्षों को स्टोर करने का सबसे अच्छा तरीका क्या है?

1. परियोजना स्रोत भंडार छोटे
2. 3 पार्टियों के साथ सिंक में परियोजना स्रोत रखें ताकि मैं हमेशा संकलन और चलाने के लिए और पुराने संस्करण कर सकते हैं के आकार रखें:

   यहाँ वरीयताओं के अपने सेट है

4. क्रॉस मंच का प्रबंधन करने के

सरल मैंने कोशिश की और के बारे में सोचा कई समाधान लेकिन न ही संतोषजनक था:

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

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

Answer 1

मेरी समस्या के लिए एक उचित समाधान git-subtree है जिसे हाल ही में मेनलाइन गिट में विलय कर दिया गया था। यह मेरी आवश्यकताओं और प्लेटफार्म सीमाओं के बीच एक उचित संतुलन प्रदान करता है। अब मेरे पास बाहरी के लिए कई भंडार हैं (प्रत्येक में एक विक्रेता शाखा के साथ-साथ स्थानीय परिवर्तन शाखा भी होती है) और प्रत्येक प्रोजेक्ट रिपोजिटरी इन बाहरी हिस्सों के हिस्सों को उप-फ़ोल्डर्स में ले जाती है। चीजों को संगठित रखने के लिए मैं एक 'बिन' और 'lib' फ़ोल्डर्स बनाए रखता हूं जिसमें बाहरी उप-फ़ोल्डर में उचित फ़ाइलों/फ़ोल्डरों के मुलायम लिंक होते हैं।

गिट-सबट्री एक उप-पेड़ को एक उप-फ़ोल्डर में एक बाहरी-संग्रह से मर्ज करने की अनुमति देता है। उप-फ़ोल्डर को बाह्य भंडार के साथ आगे और पीछे विलय किया जा सकता है।

पेशेवरों/विपक्ष:

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

2. प्रोजेक्ट/बाहरी सिंक - जैसा कि प्रोजेक्ट और बाहरी एक ही भंडार में संस्करणित हैं, मैं किसी भी शाखा/टैग मैं चाहता हूं और यह काम करने की उम्मीद है।

3. सरलता - दिन-दर-दिन काम सीधे आगे है। बाहरी भंडार को अद्यतन करना, नया बनाना या बाहरी के किसी भिन्न संस्करण में स्विच करना मुश्किल हो सकता है और विशेष वाक्यविन्यास की आवश्यकता होती है। हालांकि यह बहुत अधिक होता है। सबसे अच्छी बात यह है कि कोई भी इस परियोजना के लिए पहले एक नया बाहरी जोड़ सकता है और इसके बाद ही इसे अपने स्वयं के भंडार में (गिट-सबट्री का उपयोग करके) विभाजित कर सकता है।

4. क्रॉस मंच - वैसे यह Git

5. बाइनरी है - मैं बजाय बाइनरी पकड़े बचने और Makefiles प्रदान करने के लिए फैसला किया। मैं इस फैसले पर आया क्योंकि मेरे कुछ बाहरी बाहरी हिस्सों पर निर्भर करते हैं जो बाइनरी बनाने में बहुत मुश्किल बनाता है जो अक्सर नहीं बदलता है। कुछ बाहरी लोगों के लिए मैं बहुत लंबे समय तक निर्माण के कारण बाइनरी स्टोर करता हूं।

संरचना:

/root 
    /External 
     /External1 (git-subtree from git@git.domain.com:External1 v1.0) 
     /External2 (git-subtree from git@git.domain.com:External2 v0.7) 
    /lib 
     /libExternal1.a -> ../External/External1/libExternal1.a 
     /libExternal2.a -> ../External/External1/libExternal2.a 
    /include 
     /External1 -> ../External/External1/include 
     /External2 -> ../External/External2/include 

Answer 2

हम आपके विकल्प के एक संस्करण के लिए गए हैं 3. विकल्प 1 मुझे विकल्प 3 के बराबर समझा जाता है, लेकिन आपके हिस्से पर अधिक कार्यान्वयन/परीक्षण प्रयास के साथ और इसलिए गलत होने की अधिक संभावना है।

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

Answer 3

तीसरे पक्ष के स्रोतों के लिए, मुझे लगता है कि submodules वही हैं जो आप खोज रहे हैं। यदि आप प्रत्येक क्लोन में पूरे अपस्ट्रीम इतिहास की आवश्यकता नहीं चाहते हैं, तो अपने आप के साथ अपस्ट्रीम रेपो को आगे बढ़ाएं, जिसमें केवल आवश्यक इतिहास के साथ एक हस्तशिल्प शाखा शामिल है। उन्हें बनाने के लिए git commit-tree पर देखें, यह आसान है।प्रतिबद्ध आईडी आधिकारिक अपस्ट्रीम से मेल नहीं खाएगी, लेकिन पेड़ आईडी की इच्छा होगी।

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

यह टर्नकी नहीं है, इसलिए यह वास्तव में आपके तीसरे से मेल नहीं खाता है, लेकिन यह बाकी की नाखून करता है और आपको जो चाहिए वह मूल उपकरण का सरल उपयोग है।