क्या सोर्स कंट्रोल के तहत फ्रेमवर्क रनटाइम स्टोर करना अच्छा अभ्यास है?


9

मुझे पता है कि बहुत सारी सॉफ़्टवेयर दुकानें बायनेरिज़ को स्रोत नियंत्रण में रखती हैं । हालांकि, हमारी दुकान रिपॉजिटरी पर पूरे ढांचे को संग्रहीत करने के लिए आई थी: डायरेक्टएक्स रनटाइम, सीयूडीए, एनवीडिया ऑप्टिक्स, जो भी हो।

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

मैंने ऐसा उपयोग पैटर्न कभी नहीं देखा है। क्या आप इसे एक अच्छा अभ्यास मानते हैं?

[संपादित:] मुझे स्रोत-नियंत्रित पृथक 3 पार्टी बायनेरिज़ के साथ कोई समस्या नहीं है। यह प्रश्न पूरे फ्रेमवर्क रनटाइम को संदर्भित करता है, जिसमें आमतौर पर 10+ बायनेरिज़ शामिल होते हैं। एक चरम उदाहरण के रूप में, विंडोज एसडीके (जिसे हम रिपॉजिटरी पर नहीं रखते हैं, भगवान को धन्यवाद दें, लेकिन मुझे सिद्धांत में कोई अंतर नहीं दिखता है)।


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

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

मैं ब्लोट के बारे में सहमत हूं (विशेषकर यदि उन रनटाइम को कई परियोजनाओं के बीच साझा किया जाता है), लेकिन मैं अप्रासंगिक इतिहास के बारे में समझ नहीं पा रहा हूं। उदाहरण के लिए एक परिवर्तन जिसमें आपके द्वारा उपयोग किए जा रहे रनटाइम का संस्करण काफी प्रासंगिक है ...
6502

क्या अपडेट के लिए डेवलपर मशीन की छवियां बनाना आसान नहीं होगा?
रामहुंड

@ रामध्वज: यही सटीक दिशा है जिसे मैं आगे बढ़ाने की कोशिश कर रहा हूं। मुझे आश्चर्य है कि अगर वहाँ नीचे मैं गायब हूँ।
तोक शिलोन

जवाबों:


6

बायनेरिज़ आमतौर पर संस्करण नियंत्रण प्रणाली के लिए अच्छी तरह से अनुकूल नहीं हैं क्योंकि:

  • वे संस्करण नियंत्रण सुविधाओं (विलय, अंतर) से लाभ नहीं लेते
  • वे रेपो के आकार में वृद्धि ...
  • ... जो मायने रखता है क्योंकि आप आसानी से एक VCS से एक संस्करण को नहीं हटाते हैं (VCS को इतिहास रखने के लिए बनाया गया है), नेक्सस जैसे विरूपण साक्ष्य रिपॉजिटरी के विपरीत , जो सरल साझा निर्देशिका (साफ करने के लिए आसान: + ) हैं!cdrm
  • उन्हें VCS में पाठ के रूप में संदर्भित किया जाना चाहिए , पथ + संस्करण की घोषणा : आप प्रासंगिक इतिहास को उस तरह से रख सकते हैं, बाइनरी संस्करण के किसी भी परिवर्तन को उस पाठ फ़ाइल में परिवर्तन के रूप में रिकॉर्ड कर सकते हैं (जैसे कि pom.xml यदि आप Nexus उपयोग कर रहे हैं उदाहरण के लिए)

1
अंतिम बिंदु बहुत मूल्यवान है।
नौफाल इब्राहिम

धन्यवाद! क्या आप C ++ परियोजनाओं के लिए एक समान विरूपण साक्ष्य भंडार के बारे में जानते हैं? इससे भी बेहतर - शायद एक जो टीएफएस के साथ एकीकृत हो?
तोक शिलोन

2
@OfekShilon: नेक्सस सिद्धांत में किसी भी तरह की कलाकृतियों को संग्रहीत कर सकता है। लेकिन .NET / C ++ के लिए भंडारण और निर्भरता प्रबंधन के लिए, आपके पास NuGet: nuget.codeplex.com भी है । उदाहरण के लिए .Net: Lostechies.com/derekgreer/2011/09/20/… । इसे C ++ प्रोजेक्ट्स को भी सपोर्ट करना चाहिए: nuget.codeplex.com/discussions/280649
VonC

@OfekShilon आप TFS को NuGet (उदाहरण के लिए: coolthingoftheday.blogspot.com/2011/08/… , hanselman.com/blog/… ) से जोड़ सकते हैं । TFSNuGetter भी देखें: nugetter.codeplex.com
VonC

6

मैं द्विआधारी संपत्ति को नियंत्रित करने वाले संस्करण के साथ ठीक हूं। मैं उत्पन्न फ़ाइलों को नियंत्रित करने वाले संस्करण के खिलाफ हूं ।

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

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


3

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

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

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


2

मुझे लगता है कि बायनेरी कहीं स्टोर होनी चाहिए। मैं उन्हें एक भंडार के बाहर संग्रहीत करने का सुझाव दूंगा, खासकर यदि वे बड़े हैं और बड़े चेक आउट के लिए नेतृत्व करते हैं। मैं इसे खराब अभ्यास नहीं देख रहा हूँ, लेकिन यह भी मैंने नहीं देखा है।

यह वास्तव में एक अच्छा विचार हो सकता है यदि आपके संगठन में बहुत सारी परियोजनाएं हैं जो विभिन्न रनटाइम संस्करणों को लक्षित करती हैं। यह सुनिश्चित करता है कि आपके पास सही रनटाइम बाइनरी है जब आप सही प्रोजेक्ट्स पर काम कर रहे हैं।


मैंने इसे संबोधित करने के लिए प्रश्न को स्पष्ट कर दिया है।
तोक शिलोन

1

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


1

ऐसा करने आप सभी आप एक में की जरूरत है अर्थात् है कि, के लिए एक अच्छा कारण है ही किसी भी बाहरी निर्भरता के बिना, स्थान।

यह आपके विचार से बहुत अधिक महत्वपूर्ण है। यह अनिवार्य रूप से सुनिश्चित करता है कि आप एक विक्रेता सर्वर पर एक विरूपण साक्ष्य पर भरोसा नहीं करते हैं जो कुछ वर्षों के बाद दूर हो सकता है, क्योंकि आपके पास घर में सब कुछ है।

रिपॉजिटरी ब्लोट के बारे में। यह केवल एक समस्या है यदि आपका VCS एक पूर्ण स्थानीय प्रति रखता है (क्लोन ऐसा करता है, cvs नहीं करता है) क्योंकि क्लोनिंग और / या अपडेट धीमा हो जाएगा। बदले में आपके पास प्रत्येक विकास मशीन पर प्रतियां होंगी, जो आपकी कंपनी को बचा सकती है यदि किसी कारण से आपकी केंद्रीय बैकअप योजना किसी दिन विफल हो जाती है।

यह प्राथमिकता या नीति का मामला है। जब तक फैसला जानबूझकर किया जाता है, मैं इसके साथ ठीक रहूंगा।


2
यदि आप अपने स्वयं के नेक्सस या NuGet सर्वर की तरह एक विरूपण साक्ष्य भंडार पर अपने तीसरे पक्ष के पुस्तकालय को स्टोर करते हैं, तो आपको "विक्रेता" सर्वर के चले जाने का डर नहीं होगा। तो हर तरह से, उन्हें स्थानीय रूप से संग्रहीत करें। बस एक VCS का उपयोग न करें। वे उस तरह की फाइल रखने के लिए नहीं हैं।
VonC

@VonC आपके इन्फ्रास्ट्रक्चर और वर्किंग मैथोलॉजी पर निर्भर करता है। "बस एक बार एक बाइनरी स्टोर करें" के लिए एक वीसीएस सिर्फ एक पूर्ण विरूपण साक्ष्य भंडार के रूप में ठीक हो सकता है। यह बुनियादी ढाँचा भी सरल रखता है। मैं वकालत नहीं कर रहा हूं - ओपी ने पूछा कि क्या किसी ने इस तरह का उपयोग पैटर्न देखा है।

ठीक है। मैंने ऐसा उपयोग पैटर्न देखा है। एंडी को इस तरह के रेपो का प्रबंध करना था (मुख्य रूप से एसवीएन या क्लियरकेस जैसे सेंट्रलाइज़ वीसीएस, डीवीसीएस के लिए यूआईटी जैसे उपयोग कभी नहीं देखे गए)। और यह आमतौर पर एक गड़बड़ है। विक्रेता पुस्तकालयों के बारे में, आप शायद ही कभी एक बार एक द्विआधारी स्टोर करते हैं। आपको पैच से निपटना होगा। बहुत से। प्लस स्टोरेज एकमात्र लक्ष्य नहीं है (यदि यह था, तो वीसीएस यकीनन एक संभावित समाधान हो सकता है)। निर्भरता प्रबंधन है और यह कि नेक्सस या NuGet क्या प्रदान करता है (एक आसान से प्रशासन और सफाई के अलावा) भंडारण।
VonC
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.