मल्टी-जीबी एसवीएन रेपो को जीआईटी में ले जाना

Question

वर्तमान में मेरी कंपनी ने SVN रेपो में एक विजुअल स्टूडियो सॉलिशन दिया है जो इस प्रकार है:

SolutionFolder (~3.5 GB)
|-> SolutionName.sln
|-> .. Some source code folders... (~250 MB)
|-> ThirdParty (~3 GB)
|-> Tools
    | -> Tool1
    | -> Tool2

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

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

इस परियोजना संरचना को आगे बढ़ाने के लिए सबसे अच्छा तरीका क्या होगा? संभवतः यह मुख्य रेपो से थर्डपार्टी और संभवतः टूल्स को बाहर करने के लिए सबसे अच्छा है, लेकिन हम थर्डपार्टी को एक चरण में आसानी से डाउनलोड करने योग्य रखना चाहेंगे, और हम इसे पसंद करते हैं (और मुख्य रेपो और थर्डपार्टी / टूल्स के बीच संस्करण बेमेल होगा)।

इस बिंदु पर मुझे इतिहास को संरक्षित करने में कोई दिलचस्पी नहीं है, बस यह पता लगाना है कि इस तरह की परियोजना को कैसे व्यवस्थित किया जाए।

Comments

क्या वे आकार रेपो के भीतर के आकार हैं, जिनमें इतिहास भी शामिल है, या वे स्थानीय कार्य प्रतिलिपि के आकार हैं?

— डॉक्टर ब्राउन

@DocBrown में केवल स्थानीय कामकाज की प्रतिलिपि है, इसमें इतिहास शामिल नहीं है।

— --ख

Answer 1

नौकरी के लिए उचित उपकरण का उपयोग करें। विंडोज में, इसका मतलब है कि

तृतीय-पक्ष निर्भरता के लिए NuGet का उपयोग करें

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

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

टिप्पणियों के बाद संपादित करें: NuGet का उपयोग करने का सबसे अच्छा तरीका एक स्थानीय NuGet स्रोत सेट करना है, या तो एक साझा ड्राइव या एक पूर्ण नगेट सर्वर पर। सेटअप को किसी भी तरह से अधिक मिनट नहीं लेना चाहिए। इस तरह, आप गारंटी दे सकते हैं कि आपके लिए आवश्यक सभी पैकेज हमेशा उपलब्ध हैं, चाहे वे किसी भी स्थान पर उत्पन्न हुए हों।

Comments

क्या NuGet कमांड लाइन का समर्थन करता है? मैं हमेशा एक ऐसे पोर्टेबल बिल्ड की तलाश में रहता हूं जिससे मुझे जेनकिन्स मिल सके और मेरे लिए टेस्ट हो सके। क्या NuGet जेनकींस जैसे CI सर्वर का समर्थन करता है?

— अनकंटेल

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

— अनकंटेल

@uncletall: हाँ, NuGet का पूरा कमांड लाइन इंटरफ़ेस है। और यह विचार एक स्थानीय नुगेट रिपॉजिटरी को सेटअप करने के लिए है, जो नेटवर्क शेयर पर एक फ़ोल्डर हो सकता है (जिसे "फीड" कहा जाता है, docs.nuget.org/docs/creating-packages/… )

— डॉक्टर ब्राउन

हां, मैंने यह माना कि आप स्थानीय दर्पण का उपयोग करते हैं। मैं जवाब अपडेट कर दूंगा।

— विल्बर्ट

@ शेख बाहरी निर्भरताओं के लिए नगेट पैकेज बनाने के लिए यह काफी सरल और सीधा-सरल है। मुझे 50 डीएल के साथ 9 निर्भरता पैकेज करने के लिए लगभग आधे दिन की आवश्यकता थी, पहले कभी ऐसा नहीं किया।

— विल्बर्ट

Answer 2

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

आप तीसरे पक्ष के पुस्तकालयों के लिए सबमॉड्यूल्स का उपयोग भी कर सकते हैं, लेकिन यदि संभव हो तो मैं उन लोगों के लिए एक निर्भरता प्रबंधक का उपयोग करने की सलाह दूंगा।

Answer 3

वे इकाइयाँ जो आप git रिपॉजिटरी में बदल देती हैं, आवश्यक रूप से वे इकाइयाँ हैं जो आप संस्करण और शाखा; अगर SolutionFolder/Tools/Tool1ऐसी एक चीज से मेल खाती है, तो यह इकाई का स्तर है। इसका कारण यह है कि git डायरेक्टरी ट्री की पूरी स्थिति को वर्टेबल एंटिटी मानता है, जबकि svn के साथ यह संभव है (भले ही अच्छा आइडिया न हो) trunk, ट्री के भीतर branchesऔर tagsकहीं भी।

व्युत्पन्न कलाकृतियों को भंडार में नहीं रखा जाना चाहिए, न ही बाहरी पुस्तकालयों में। उन्हें संभालने के बेहतर तरीके हैं। (यदि आप जावा के साथ काम कर रहे हैं, तो एक निजी मावेन भंडार का उपयोग करने पर विचार करें; वे तुलनात्मक रूप से काम करना आसान है, और कई अन्य चीजों के साथ अच्छी तरह से एकीकृत करते हैं।)

यदि आप एक वर्कफ़्लो के लिए उपयोग किए जाते हैं जिसमें चेकआउट में आसानी के लिए एक रेपो में सब कुछ है, तो ऐसी स्क्रिप्ट पर विचार करें जो इसके बजाय चीजों को सेट करती है।

Comments

बाहरी पुस्तकालयों के प्रबंधन के लिए क्या विकल्प हैं? हम C + और C # के साथ विजुअल स्टूडियो पर काम करते हैं, इसलिए मावेन एक अच्छे फिट की तरह नहीं दिखते। यहाँ मुख्य मुद्दा यह है कि ThirdPartyरेपो में फ़ोल्डर का होना बहुत सुविधाजनक है, और अच्छे विकल्प के साथ आना मुश्किल है।

— --ख

@ शेख: एक विज़ुअल स्टूडियो वातावरण में, आप आमतौर पर इसके लिए Nuget का उपयोग करेंगे, docs.nuget.org , जो पहले से ही VS 2012 और नए संस्करणों में शामिल है।

— डॉक्टर ब्राउन

Answer 4

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

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

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

Comments

हालांकि मैंने आपको एक +1 दिया, क्योंकि "सब कुछ छोड़ दो क्योंकि यह एक व्यावहारिक समाधान है", मुझे लगता है कि "मल्टीपल रिपोज" एकमात्र समस्या नहीं हो सकती है। DVCS जैसे Git में कई स्थानीय शाखाएँ होने के लिए प्रोत्साहित किया जाता है, और प्रत्येक शाखा में हर चीज़ की एक पूरी स्थानीय प्रतिलिपि होती है। तो इससे स्थानीय प्रतिलिपि के रूप में एक ही बड़ी थर्ड पार्टी लाइब्रेरी (आमतौर पर एक ही संस्करण!) हो सकती है। यह कुछ स्थितियों में संभव हो सकता है, दूसरों में मैं कल्पना कर सकता हूं कि इससे ब्रांचिंग और विलय के प्रदर्शन पर नकारात्मक प्रभाव पड़ेगा।

— डॉक्टर ब्राउन

जहाँ तक मुझे पता है, Git में एक शाखा बहुत सस्ता ऑपरेशन है जो केवल एक पॉइंटर बनाएगा और लगभग शून्य स्थान लेगा।

— अनकंटेल

@DocBrown संबंधित: Git में "ब्रांचिंग फ्री" का क्या अर्थ है?

जब तक मुझे कुछ याद नहीं आ रहा है, शाखाएं Git में "मुक्त" हैं। मैंने अभी-अभी अपने .गित / रेफ्स / हेड्स की जाँच की है और सभी शाखाएँ 1KB टेक्स्ट फाइल्स हैं, .it / लॉग्स / रेफ्स / हेड्स में वे लॉग्स शामिल हैं जहाँ मास्टर के लिए सबसे बड़ी 11KB है .. मेरी सामान्य प्रोजेक्ट संरचना कोड में लगभग 500MB है। तीसरे पक्ष के काम और अन्य उपकरण। मैं एक शाखा बनाने के लिए 1KB हिट लेने के लिए बहुत खुश हूँ

— जेनेट

@ मिचेल्ट: ब्रांचिंग अपने आप में नि: शुल्क है, बेशक, लेकिन मैं उस स्थिति की बात कर रहा हूं जहां आपके पास समानांतर में आपके स्थानीय वर्कस्टेशन पर विभिन्न शाखाओं की कई कार्यशील प्रतियां हैं। और यदि आप मूल प्रश्न के नीचे टिप्पणियों की जांच करते हैं, तो ओपी कार्यशील प्रतिलिपि के आकार के रूप में 3 जीबी तृतीय पक्ष टूल का उल्लेख कर रहा था।

— डॉक्टर ब्राउन