क्या आप अपने टीएफएस में बिन या डिबग फोल्डर (और डीएलएस) की जांच करते हैं?


11

TFS के बारे में क्विक क्वेश्चन - क्या आप लोग TFS में चेक-इन बिन / डिबग फोल्डर में हैं? (यदि ऐसा है, तो क्यों?) चूंकि उन फ़ोल्डरों की सामग्री गतिशील रूप से उत्पन्न होती है, तो क्या उन्हें बाहर छोड़ना बेहतर है ताकि प्रोग्रामर केवल-पढ़ने के मुद्दों में नहीं चलेगा?


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

जवाबों:


27

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

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


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

8

सरल उत्तर? नहीं, यह मत करो! मैं नहीं करने के लिए कई कारणों के बारे में सोच नहीं सकते, लेकिन कोई कारण नहीं है कि आप क्यों करना चाहते हैं।

केवल एक बार जब आप सोच सकते हैं कि आप एक dll में जांच करेंगे अगर यह किसी तीसरे पक्ष के पुस्तकालय से है, तो आपको उम्मीद नहीं है कि प्रत्येक डेवलपर के निर्माण के लिए स्थापित किया गया है। लेकिन फिर भी, यह बिन फ़ोल्डर में स्थित नहीं है।

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


1
मुख्य कारण यह नहीं है: आप अपने स्रोत नियंत्रण का उपभोग करने के लिए कितने संग्रहण स्थान चाहते हैं?
EKW

1
उदाहरण के लिए @EKW C # समान स्रोत से समान बायनेरिज़ का उत्पादन नहीं करता है। यह .NET कोर के साथ अब अलग हो सकता है लेकिन उदाहरण के लिए रिलीज़ किए गए बिल्डरों के लिए उत्पन्न बायनेरिज़ को रखने का यह एक कारण था। मैं हालांकि उन्हें स्रोत नियंत्रण में नहीं रखूंगा। यह उस काम के लिए सही उपकरण नहीं है।
शिव

5

हम बिन फ़ोल्डर में टीएफएस में जांच नहीं करते हैं। जैसा कि आपने शायद देखा है, यदि आप ऐसा करते हैं, तो हर बार कोई भी डेवलपर समाधान बनाता है, वे बिन फ़ोल्डर की जाँच करेंगे। अच्छा नही। हालाँकि ऐसे पुस्तकालय हैं जिन्हें परियोजना को संकलित करने और चलाने के लिए आवश्यक है, और हमारा नियम है कि किसी भी परियोजना को स्रोत नियंत्रण से खोला जा सकता है, और इसे संकलित और चलाना चाहिए। तो हम जो भी करते हैं, वह किसी भी DLL के लिए एक "BinRef" फ़ोल्डर बनाता है, जिसके लिए प्रोजेक्ट का संदर्भ होना चाहिए, और BinRef फ़ोल्डर में प्रतिलिपि के लिए प्रोजेक्ट संदर्भ बनाना चाहिए। BinRef फ़ोल्डर है TFS करने के लिए जाँच की।

इस दृष्टिकोण का दूसरा फायदा यह है कि BinRef हमेशा वेब प्रोजेक्ट के मूल स्तर पर होता है। यदि मेरा प्रोजेक्ट अंदर रहता है C:\Projects\Marcie\SomeProjectCategory\ProjectAऔर मैं एक DLL का संदर्भ बनाता हूं C:\DLLsThatILike, जो संदर्भ में बैठता है , तो संदर्भ कुछ इस तरह दिखाई देगा

\..\..\..\NiceThing.dll

। आप अपनी परियोजना फाइलों को रख सकते हैं, C:\ProjectAजिसका अर्थ है कि नाइसटींग का परियोजना संदर्भ आपकी मशीन पर उड़ जाएगा। उम्मीद है कि लोग इस तरह से संदर्भ नहीं दे रहे हैं, लेकिन मैंने देखा है कि ऐसा होता है।


2

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


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

@ user7676 - आप उत्पादन में संस्करण संख्या पर कोड को फिर से जोड़ सकते हैं। लेकिन अगर आपके पास कोई डॉ प्लान नहीं है और आप किसी तरह के डिएस्टर में हैं तो यह आसान और तेज होगा। पुनश्च। आप एक डॉ योजना की जरूरत है !!!
अली

1

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


0

नहीं, लेकिन हमारे घर में परियोजना नियंत्रण उपकरण स्वचालित रूप से करता है, जो मुझे बाहर निकालने की कोशिश करता है।

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


0

मैं उन्हें स्रोत नियंत्रण में प्रवेश करने से रोकता हूं। वे अनावश्यक जानकारी रखते हैं, बायनेरिज़ को उस संशोधन में स्रोत कोड द्वारा बनाया जा सकता है। इसके अतिरिक्त, स्रोत कोड हमेशा अद्यतित होता है, बिल्ड कमिट नहीं हो सकते हैं।


0

मैं कुछ उत्पन्न बाइनरी फ़ाइलों को सहेजता हूं, जैसे .NET किसी अन्य प्रोजेक्ट से इंटरॉप करता है। इसलिए यदि मेरे पास एक प्रोजेक्ट A है जो COM ऑब्जेक्ट बनाता है, और फिर आप उस COM ऑब्जेक्ट का उपयोग बहुत ही शिथिल रूप से संबंधित प्रोजेक्ट B में करते हैं, जो इसे .NET इंटरॉप के माध्यम से उपयोग करता है, तो मैं प्रोजेक्ट A से प्रोजेक्ट बी में उत्पन्न उस इंटरॉप में जांचता हूं। एक अच्छा विचार नहीं है, लेकिन इसे कहीं और जाना है क्योंकि AFAIK विजुअल स्टूडियो बिल्ड के दौरान आपके लिए इंटरोप नहीं बनाएगा।


-2

मेरी राय में, स्रोत नियंत्रण में बायनेरिज़ को संग्रहीत नहीं करना सबसे आम गलतियों में से एक है। उन्हें स्रोतों के साथ संग्रहीत, संस्करणबद्ध, आधारभूत / लेबल किया जाना चाहिए और उपकरण भी बनाने चाहिए। नहीं रहने योग्य सॉफ्टवेयर के निर्माण के साथ खुद को सूट करें ...


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