क्या आप हमेशा अपने सबवर्जन भंडार के शीर्ष स्तर पर शाखाएं, टैग और ट्रंक निर्देशिका डालने के सम्मेलन का पालन करते हैं? हाल ही में, मैंने परेशान करना बंद कर दिया है और कुछ भी बुरा नहीं हुआ है (अभी तक)!क्या आप शाखाओं/टैग/ट्रंक सम्मेलन का उपयोग करते हैं?
यदि उन्हें बनाने की आवश्यकता हो तो निर्देशिका पेड़ को स्थानांतरित करना संभव होना चाहिए। क्या मैं बाद में परेशानी का निर्माण कर रहा हूं?
क्या आपने अभी तक ब्रांचिंग या टैगिंग करने का प्रयास किया है? तब तक, कोई समस्या नहीं है। हालांकि, शाखाओं, टैग, ट्रंक सम्मेलन का उपयोग करने का एक अतिरिक्त लाभ यह है कि यह बिल्कुल है - एक सम्मेलन। लोग इसे देखने की उम्मीद करते हैं, इसलिए उन्हें पता है कि उन्हें फोर्क की आवश्यकता होने पर क्या करना है।
नहीं, वर्तमान में कतार में परियोजनाओं के लिए उस दृष्टिकोण को त्याग दिया है। हालांकि अवधारणा बहुत मान्य प्रतीत होती है, लेकिन यह प्रैक्टिस में बचाए जाने की तुलना में अधिक समय बर्बाद कर रही है।
जब तक आपको कोई शाखा बनाने या रिलीज टैग करने की आवश्यकता न हो। उस समय आप मौजूदा कोडबेस को चारों ओर ले जाने वाले डेवलपर प्रयास के घंटों को बर्बाद कर देंगे। शुरुआत में उन निर्देशिकाओं को बनाने के लिए 30 सेकंड लेना आसान है। –
क्षमा करें क्षमा करें, आवश्यकतानुसार शाखा या टैग बनाने में घंटों लगते हैं ... –
नहीं, लेकिन एक बार जब आप रूट से अपने कोड को ट्रंक में ले जाते हैं तो आपके पास डेवलपर्स का एक पूरा समूह होता है और कुछ भी –
यह इस बात पर निर्भर करता है कि परियोजना कितनी बड़ी है। हमारे पास कुछ सामान है (गिट में दिया गया है, लेकिन अवधारणा वही है) जो काफी बड़ी है। प्रत्येक डेवलपर अपनी शाखा का उपयोग करता है, वहां एक परीक्षण और मुख्य रेखा शाखा होती है। हम रिलीज को भी टैग करते हैं, और यदि संस्करण-विशिष्ट फिक्स हैं, तो एक शाखा बनाई गई है ताकि फिक्स को काफी आसानी से एकीकृत किया जा सके।
इस सेटअप में फायदे हैं: हम विकास के दौरान एक दूसरे के बालों में नहीं आते हैं। लेकिन नकारात्मक बात यह है कि हमें डेवलपर्स शाखा से परीक्षण शाखा में और फिर मुख्य लाइन में आने के लिए एक इंटीग्रेटर की आवश्यकता होती है।
यदि परियोजना छोटी है, तो यह सिर्फ ऊपर की ओर है, लेकिन आप कभी नहीं जानते कि कोई परियोजना कितनी बड़ी होगी।
टैग पर इंगित स्वचालित प्रक्रियाएं होती हैं गिट में कम से कम उपयोगी हैं - आप देख सकते हैं कि कौन सा टैग पहले से/बाद में है, वे काम करने के लिए निमोनिक्स के रूप में कार्य करते हैं, इत्यादि। उपवर्तन टैग में द्वितीय श्रेणी के नागरिक और समय की पूरी बर्बादी होती है। आप "svn log -r (टैग-नाम)" या जो कुछ भी नहीं कर सकते। यहां तक कि सीवीएस ने टैग बेहतर किया। – richq
एसवीएन सब कुछ एक निर्देशिका के रूप में व्यवहार करता है। शाखा को टैग करने के लिए, आप इसे ./tags/ निर्देशिका में निर्देशिका में कॉपी करते हैं। इसी तरह एसवीएन में शाखाओं के लिए। गिट शाखाओं और टैगों में आदर्श हैं और उचित – Rory
क्या आपके पास कम से कम एक ट्रंक है? यदि नहीं, तो आपको शाखा या टैग करने की आवश्यकता होने पर, आपको वास्तविक कोड/सामग्री के साथ-साथ अपनी रूट प्रोजेक्ट निर्देशिका में बैठना होगा। ओह!
संपादित करें: मुझे लगता है कि आप एक ट्रंक फ़ोल्डर बना सकते हैं, तो उस में सब कुछ ले जाते हैं, तो आपके शाखाओं आदि बनाने ...
कहा, "बस इसे बाद में कर, समय बर्बाद मत करो, आदि लोगों के लिए.. "ईमानदारी से हालांकि, अपने प्रोजेक्ट के शुरू में उन्हें बनाने के लिए कितना ओवरहेड है? 2 मिनट, सबसे ऊपर? ऐसा क्यों न करें? बाद में सब कुछ स्थानांतरित करने में अधिक समय लगेगा - भले ही आप केवल 5 बार शाखा 1 की आवश्यकता हो, फिर भी मुझे लगता है कि आप शाखा, टैग, ट्रंक संरचना से शुरू होने वाले कम समय का उपयोग करेंगे।
किया गया है, उन्हें बनाने का समय नहीं है, रोजमर्रा के उपयोग के दौरान अतिरिक्त पथ तत्व टाइप करने की आवश्यकता है जो मुझे परेशान करता है! ~~~ –
क्यों कई एसवीएन फ्रंटेंड्स (आईडीई एकीकरण, TortoiseSVN, आदि) का उपयोग नहीं करते? –
मैंने वास्तव में सम्मेलन का उपयोग करना शुरू कर दिया, और मैं with Danimal से सहमत हूं। यदि आपके पास क्यूए में एक निर्माण है, और दूसरा उत्पादन में है, और दूसरा पागल-नए-प्रयोगात्मक फीचर डेवलपमेंट में है, तो जल्दी से आगे बढ़ना अच्छा होता है।
जैसा कि मैंने What do "branch", "tag" and "trunk" mean in Subversion repositories? में कहा था, चूंकि शाखा और टैग समान हैं, इसलिए आप किसी भी सम्मेलन का पालन करने के लिए बाध्य नहीं हैं। विशेष रूप से अनुक्रमिक विकास के साथ एक छोटे से परियोजना के लिए
(यानी वर्तमान विकास, पुराने संस्करणों के रखरखाव, वैकल्पिक व्यवस्थाएं की खोज के बीच समानांतर प्रयासों के लिए कोई ज़रूरत नहीं, ...)
मैं आम तौर पर की जड़ में मेरे ट्रंक रखेंगे भंडार और केवल मुझे एक ट्रंक फ़ोल्डर में ले जाना है यदि मुझे वास्तव में एक शाखा का टैग बनाने की आवश्यकता है। मुझे एसवीएन के साथ लगता है, जब तक आपकी संरचना तार्किक है, आपको अपनी जरूरतों को बदलने के बाद बाद में इसे फिर से व्यवस्थित करने में कोई परेशानी नहीं होनी चाहिए।
मैं प्रत्येक प्रोजेक्ट पर ट्रंक, टैग और शाखाओं का उपयोग करता हूं। गंभीरता से, जब आप प्रोजेक्ट बनाते हैं तो 2 अतिरिक्त निर्देशिकाएं बनाना कितना मुश्किल है। स्थिरता बनाए रखने के लिए सम्मेलन का पालन करने के लिए कुछ लाभ है।मुझे लगता है कि मेरे पास बहुत सारे टैग हैं (डेवलपर पर्यावरण के बाहर एक ऐप का प्रत्येक धक्का संस्करण और टैग हो जाता है)। मेरे पास इतनी सारी शाखाएं नहीं हैं क्योंकि मैं आम तौर पर लोगों के साथ काम नहीं कर रहा हूं, मुझे समीक्षा से पहले प्रतिबद्धता पर भरोसा नहीं है। इसलिए, आमतौर पर जब मुझे शाखाएं मिलती हैं, तो ऐसा इसलिए होता है क्योंकि मेरे पास कोडबेस का स्थायी विभाजन होता है - आमतौर पर विभिन्न ग्राहकों के लिए। एक बार जब कोड असहनीय हो जाता है, तो मैं आम तौर पर एक शाखा को रोकता हूं और इसे अपने स्वयं के ट्रंक में ले जाता हूं।
हाल ही में मैं एक मॉडल का उपयोग करके फुर्ती में अधिक ध्यान केंद्रित कर रहा हूं और आप here देख सकते हैं।
वर्जन कंट्रोल में कुछ नीतियों का पालन करना वास्तव में महत्वपूर्ण है, क्यूज़ भी एक अच्छी तरह से परिभाषित मॉडल का उपयोग करके, कोड संस्करण प्रकृति में कुछ है जो आपको गलतियों, गन्दा विलय, और सभी बुरी चीजों को करने के लिए प्रेरित करता है, इसलिए सावधान रहें ।
यह मॉडल प्रत्येक भंडार के लिए जिम्मेदारियां देता है और आपको उत्पादन, वितरण योग्य और निर्माणाधीन कोड कहां स्थित है, इसे ओवरलैप नहीं करने देता है।
मैं कई कारणों
संक्षेप में यह तुरंत स्पष्ट नहीं हो सकता कि सम्मेलन एक अच्छी बात क्यों है, लेकिन जब आपको सहायता, सलाह, या कुछ प्रबंधन पागलपन की आवश्यकता होती है तो यह एक प्रख्यात देवता बन जाती है।
मुझे अवधारणाओं के सरल प्रमाण के लिए "मिनी-प्रोजेक्ट" के लिए शाखाओं का उपयोग करना पसंद है। यह तेज़, आसान है और आम तौर पर आपके मुख्य प्रोजेक्ट को बनाए रखने में मदद करता है। मैंने शाखा निर्देशिका में अवधारणाओं का प्रमाण रखा क्योंकि यह मुख्य परियोजना के अलावा नहीं है बल्कि यह परियोजना के लिए मूल्यवान है।
दूसरों की तरह उल्लेख किया गया है, मैं रिलीज के लिए टैग का उपयोग करता हूं। मेरे द्वारा किए जाने वाले अधिकांश रिलीज़ संस्करणों में हैं इसलिए मेरे पास आमतौर पर पैकेज या संस्करण के इंस्टॉलर की ज़िप फ़ाइल होती है।
त्वरित उत्तर "जो भी आपकी प्रक्रियाओं के अनुरूप सर्वोत्तम है" करें।
जैसा कि दानिमल ने कहा कि शाखा/ट्रंक/टैग की संरचना एक सम्मेलन है। हालांकि, मैं इस बात से सहमत नहीं हूं कि यह बी/टी/टी का स्थान है जो महत्वपूर्ण है, केवल उनका अस्तित्व है।
आपको जो चाहिए वह कहीं कहीं है जो स्पष्ट रूप से शाखाओं के लिए नामित है, कहीं आपके ट्रंक के लिए नामित है और आपके टैग के लिए भी है। वास्तव में जहां वे गिरते हैं, आपके भंडार की संरचना और आपके द्वारा रखी जा रही फ़ाइलों की प्रकृति पर निर्भर करता है।
उदाहरण के लिए, यदि आप एक रिपोजिटरी में एकाधिक प्रोजेक्ट्स रखते हैं तो आपको शायद पता चलेगा कि यह आपकी परियोजनाओं के तहत आपकी बी/टी/टी निर्देशिका बनाने के लिए और अधिक समझ में आता है। यदि आपके पास अपनी प्रोजेक्ट के भीतर अलग-अलग मॉड्यूल हैं तो मॉड्यूल निर्देशिकाओं के तहत बी/टी/टी बनाया जाना चाहिए।
खुद से पूछें कि सबसे बड़ा तार्किक हिस्सा क्या होगा कि आप शाखा बनाना चाहते हैं और इसके द्वारा निर्देशित किया जाना चाहिए।
नहीं। अंतिम 3 कार्य परिस्थितियों में नहीं। मैं उन गैर-प्रोग्रामर के साथ काम करता हूं जिन्हें प्रसंस्करण स्क्रिप्ट लिखना, ठीक करना और याद करना है। प्रोग्रामिंग ज्यादातर आकस्मिक है, कभी-कभी गहरा या बड़ा काम होता है। बड़े समय के सॉफ्टवेयर डेवलपर के अभ्यासों का पालन करने की कोई उम्मीद नहीं है। मानक भंडार शब्दावली उस क्षेत्र में उपयोग किए गए शब्दकोष के साथ संघर्ष कर सकती है जिसमें हम काम करते हैं। इसलिए हम अपनी खुद की भंडार निर्देशिका बनाते हैं।
एक बहुत ही सरल वातावरण में, आप अपने एसवीएन भंडार के शीर्ष से शाखा, टैग, ट्रंक छोड़ने से दूर हो सकते हैं। उदाहरण के लिए, यदि आप अपने विश्वविद्यालय के असाइनमेंट के लिए एसवीएन का उपयोग कर रहे हैं, तो आप अपने ग्राहक (असाइनमेंट को चिह्नित करने वाले व्यक्ति) को जारी होने के बाद कोड में बदलावों के बारे में बहुत चिंतित नहीं होंगे, और इसलिए आप समझदारी से वितरण कर सकते हैं शाखा, टैग, ट्रंक, और बस एक संरचना है। (प्रभावी रूप से, पूरी बात 'ट्रंक' है।)
यदि दूसरी तरफ, आप 700 अलग-अलग साइटों पर तैनात कोड प्रबंधित कर रहे हैं और यह अलग-अलग उत्पाद लाइनों में विभाजित है, तो आप होंगे पागल अपनी संरचना के शीर्ष के पास 'शाखा, टैग, ट्रंक' का उपयोग न करें (बीटीटी मार्ग पर जाने से पहले अपने उत्पादों को विभाजित करने के लिए एक समझदार मामला है), क्योंकि आपको यह जानने की आवश्यकता होगी कि कौन सा कोड कहां गया था, और स्पॉट फिक्स से बड़ी रीराइट गतिविधि (ट्रंक में जो सामान आप करते हैं) को अलग करने में सक्षम होने के लिए तत्काल समस्या वाले किसी साइट की सहायता करने के लिए (जो आप शाखा में करते हैं, फिर ट्रंक में विलय करें)। और यदि आप इस सवाल का जवाब देने में सक्षम होना चाहते हैं, "जब हम पैच 1.2.3 को घुमाते हैं तो फूबर काम क्यों बंद कर देता है?" तो टैग आवश्यक हैं।
मैंने एसवीएन के कुछ टुकड़ों को स्वचालित करने के लिए अतीत में टूल लिखे हैं। एक मूल भंडार बनाना उनमें से एक है। चरण 1: एक खाली भंडार बनाएँ। चरण 2: ट्रंक, शाखाएं और टैग फ़ोल्डर्स बनाएं - चरण 3: नई रिपॉजिटरी को हुक स्क्रिप्ट कॉपी करें
मेरी हुक स्क्रिप्ट्स में से एक यह सुनिश्चित करना है कि टैग निर्देशिका में आइटम संशोधित नहीं किए जा सकते हैं। इससे टैग्स का अर्थ शाखाओं से अलग होता है।
इन रिपॉजिटरीज़ में बहुत कम टैग नहीं हैं, क्योंकि वे सक्रिय सॉफ्टवेयर विकास के बजाय प्रलेखन और परियोजना प्रबंधन के लिए लक्षित हैं। –