के लिए सर्वोत्तम प्रथाओं के लिए मैं अपने सीवीएस/एसवीएन रेपो में टैगिंग शाखाकरण कैसे होने जा रहा है यह तय करने के लिए जिम्मेदार होने जा रहा हूं।सीवीएस/एसवीएन ब्रांचिंग और टैगिंग
क्या कोई साहित्य है जो मुझे सीवीएस के साथ काम करने का सबसे अच्छा तरीका समझने में मदद करेगा? या तो शाखा/टैगिंग, आदि?
धन्यवाद
फ्रीबीएसडी परियोजना में 10 से अधिक वर्षों के सीवीएस के दौरान मेरा व्यक्तिगत अनुभव है: जितना तेज़ हो सके स्विच करें। सीवीएस फाइल उन्मुख है स्नैपशॉट/चेंजसेट उन्मुख नहीं है जो विरूपण शाखाओं को बदले में दर्दनाक बनाता है। वैसे भी शाखाएं सीवीएस के साथ दर्दनाक हैं।
सीवीएस के लिए संसाधनों का सवाल है CVS Home
आप SVN के बारे में बात करना चाहते हैं तो देखते हैं, मैं SVN Book ही है और इस question सुझाव देना चाहेंगे। अंगूठे का
Cederqvist आम तौर पर सीवीएस को गाइड माना जाता है।
क्या करना है, यह आवश्यक नहीं है कि यह कैसे करें। –
समझदार नियम:
आमतौर पर आपको रिलीज़ किए गए संस्करणों को ब्रांच करने की आवश्यकता होती है ताकि आप पैच का परीक्षण और रिलीज़ कर सकें। आपके पास ब्रांचिंग के अन्य कारण हो सकते हैं।
और आप सबवर्सन के साथ निश्चित रूप से बेहतर हैं।
"हर निर्माण टैग" होना चाहिए "हर रिलीज टैग करें"? सबसे अच्छा हर प्रतिबद्धता बनाता है लेकिन प्रत्येक संशोधन के लिए एक टैग बहुत समझ में नहीं आता है .. –
मुझे लगता है कि यह कहना बेहतर है: प्रत्येक सार्वजनिक निर्माण को टैग करें। बिल्डर्स या उपयोगकर्ताओं आदि के लिए डेवलपर्स से दूर चलाएं, – abatishchev
मुझे कठोर होने की आवश्यकता नहीं दिखाई देती है, लेकिन यदि आप होने जा रहे हैं, तो "हर सार्वजनिक निर्माण" शायद ठीक है। यदि किसी बिल्ड से अगले में कुछ गलत हो जाता है, तो यदि आप अंतिम निर्माण को टैग करते हैं तो वापस रोल करना आसान होता है। –
मैं तुम्हें की सिफारिश SVN विंडोज, Git लिनक्स पर पर। सीवीएस का उपयोग न करें, यह बहुत भयानक है।
SVN Book वह है जो आपको पहले चाहिए।
प्रत्येक सार्वजनिक निर्माण (रिलीज) टैग करें। कुछ कारणों से शाखा एक प्रतिलिपि बना रही है - उदा। विकास का एक और तरीका। जब आपको आवश्यकता हो तो शाखा भंडार हर बार :)
मैं एसवीएन और सीवीएस पर दो व्यावहारिक प्रोग्रामर किताबें पढ़ने की सिफारिश करता हूं जिसे "Pragmatic Version Control Using CVS" और "Pragmatic Version Control Using Subversion" कहा जाता है।
दोनों उत्कृष्ट व्यंजन हैं जो व्यंजनों से भरे हुए हैं जो वर्णन करते हैं कि आप पहले बताए गए पुस्तकों में नट्स और बोल्ट के विवरणों के बजाय क्या करना चाहते हैं।
HTH
चियर्स,
रोब
में शाखाओं और विलय Eric Sink's Source Control HOWTO कवर बाद में प्रविष्टियों।
आपको सीवीएस छोड़ना चाहिए।सीवीएस शाखाओं/टैगिंग के मामले में बहुत तेजी से पुरानी है और नहीं है (शाखा/टैग निर्माण एक परियोजना में फ़ाइलों की संख्या पर रैखिक निर्भर करता है)
आप अपने शाखाओं में रणनीति पहले सोचना चाहिए: क्या आप एक
करना चाहते हैंयह भारी अपनी परियोजना और विकास दर्शन पर निर्भर करता है
आप, SVN उपयोग करने के लिए क्या तुम सच में अपने भंडार लेआउट के बारे में सोचना है क्योंकि लगभग सभी softwareprojects मॉड्यूल आधारित हैं चाहते हैं और आप एक संरचना खोजना चाहिए जिसमें आप आसानी से सभी आवश्यक मॉड्यूल टैग कर सकते हैं। शाखाओं/टैग के फ़ोल्डर आधारित दृष्टिकोण के साथ एसवीएन इस आवश्यकता को हासिल करना आसान नहीं है।
यह कहा गया है कि यह स्पष्ट होना चाहिए कि बहुउद्देशीय लेआउट एक स्थिर टैगिंग सिस्टम को बनाए रखना अधिक कठिन है। मैं एक "टैग सभी" दृष्टिकोण पसंद करता हूं, हालांकि यह मेरी निजी पसंद है।
> यह कहा गया है कि यह स्पष्ट होना चाहिए, कि एक स्थिर टैगिंग सिस्टम को बनाए रखने के लिए बहुआयामी लेआउट अधिक कठिन हैं। बिल्कुल सही तरीके से जानने के बिना, मुझे आश्चर्य है कि इसका उपयोग svn के उपयोग से किया जा सकता है: बाहरी टैगिंग से पहले बहु-भंडार लेआउट को खींचने के लिए बाहरी। – RjOllos
आप बाहरी का उपयोग कर ऐसा कर सकते हैं, हालांकि चीजें खराब हो जाएंगी, अगर आपके उपप्रोजेक्ट स्वयं बाहरी का उपयोग कर रहे हैं। सभी परियोजनाओं में सभी बाहरीों की तलाश करने का कोई तरीका नहीं है और यह एक से अधिक स्तरों में बाहरी बनाए रखने के लिए पीआईए है। –
मैं जीआईटी का उपयोग करने की सिफारिश करता हूं क्योंकि टैगिंग/ब्रांचिंग प्रक्रिया का उपयोग करना बेहद आसान है। एसवीएन (विशेष रूप से विंडोज़) का उपयोग करने का लाभ जीयूआई उपकरण और विंडोज शैल एकीकरण की संख्या है।
मैं एसवीएन पर व्यावहारिक प्रोग्रामर किताबों की सिफारिश भी दूसरी करता हूं।
मेरा मानना है कि इस कोडिंग आतंक से है:
शाखाओं में बंटी और मर्ज करना पर क्रिस Birmele पेपर सबसे अच्छा परिचय मैं इस आवश्यक स्रोत नियंत्रण कार्य करने के लिए मिल गया है है। शाखा के दर्जनों तरीके हैं, और इसे करने का कोई भी सही तरीका नहीं है। अपने विकल्पों के साथ familar प्राप्त करें ताकि आप जानते हैं कि प्रत्येक के साथ ट्रेडऑफ क्या हैं।
आप तोड़फोड़ के लिए 10 के लिए एक स्टार्टर चाहते हैं:
ट्रीट अपने विकास का एक पूरा इतिहास के रूप में 'ट्रंक'। जो कुछ भी कभी जारी हो जाता है वह किसी बिंदु पर और कुछ रूप में ट्रंक में दिखाई देना चाहिए।
जटिल विकास कार्यों में विकास शाखाओं (ट्रंक से शाखाएं) का उपयोग करें। जब कार्य समाप्त हो जाता है, तो शाखा से ट्रंक में परिवर्तन खींचने के लिए विलय को दोबारा एकीकृत करें। इस तरह आपके पास एक ही कार्य से संबंधित सभी काम करने के बजाए ट्रंक के लिए कुछ विशिष्ट प्रतिबद्धताएं होती हैं। इन विकास शाखाओं को हटाएं जब अब आवश्यकता नहीं है। उन्हें 'फ़ीचरएक्स'
उन संस्करणों का प्रबंधन करने के लिए संस्करण शाखाओं (फिर से ट्रंक से) का उपयोग करें जो ग्राहकों को जारी किए जाने के लिए नियत हैं/रहने के लिए तैनात हैं। एक संस्करण ट्रंक में संशोधन का सबसेट है। उनका उपयोग करने के लिए, उचित संशोधन (ट्रंक से सिर) में ट्रंक से शाखा, मैन्युअल रूप से उस शाखा में विलय होने के रूप में ट्रंक से संशोधनों को रिकॉर्ड करें, ट्रंक से केवल किसी भी अतिरिक्त संशोधन में विलय करें (केवल ट्रंक से)। सीधे संस्करण शाखा पर विकसित न करें, केवल ट्रंक से विलय करें - हालांकि विलय को संस्करण के साथ संगत बनाने के लिए अतिरिक्त कार्य की आवश्यकता हो सकती है। 'संस्करण 2' नाम।4 '
जब भी आप बिल्ड या हॉटफिक्स करते हैं जो ग्राहकों को जारी किया जाता है या लाइव में तैनात किया जाता है तो अपनी संस्करण शाखाओं से विशिष्ट टैग बनाएं। नाम '2.4.1', '2.4.2' इत्यादि।
इस तरह से कार्य करना आप संशोधन के आधार पर प्रत्येक टैग में क्या है, यह देखने के लिए आप विवर्तन के विलय-ट्रैकिंग (संस्करण 1.5 और ऊपर) का उपयोग कर सकते हैं। ऐसा करने के लिए, अपने टैग या संस्करण शाखा की एक कार्यशील प्रति प्राप्त करें और 'svn mergeinfo --show-revs विलय http://svn/trunk c: \ workingcopy \'
यह ऑडिटर, ऑटो-जेनरेट रिलीज नोट्स, परीक्षक, और वास्तव में क्या है और क्या बाहर है इसके बारे में आपका आत्मविश्वास। इस जानकारी के साथ एक ऑटो-जेनरेटेड मैट्रिक्स का उपयोग एक नज़र में देखने के लिए कि विभिन्न संस्करणों में क्या है।
आप कहते हैं कि सभी परिवर्तन पहले ट्रंक में जाना चाहिए, और सीधे संस्करण शाखा में विकसित नहीं होना चाहिए। मैं सहमत हूं, लेकिन एक संस्करण शाखा में बग फिक्स करने के बारे में क्या, जिसका कोड अब ट्रंक में उपलब्ध नहीं है (शायद कोड क्लीनअप या फीचर हटाने के कारण)? –
साल पहले (सुरक्षित स्रोत से) मेरी पहली असली एससीएम के लिए जा रहा है, मैं निम्नलिखित उपयोगी पाया - जबरदस्ती से एक श्वेत पत्र वापस तो नहीं था मुझे लगता है कि:
अच्छा, इससे कोई फर्क नहीं पड़ता कि आप किस स्रोत नियंत्रण प्रणाली का उपयोग करते हैं, वे सभी मूल रूप से ट्रंक/शाखाओं/टैग संरचना के कुछ रूपों का पालन करते हैं। भले ही यह एक वितरित मॉडल है, फिर भी इसे प्रतिबिंबित करने के लिए भंडार स्थापित किए जाएंगे।
here शुरू करने के लिए एक बहुत ही सरल व्याख्या है।
मैंने केवल कुछ वर्षों तक सीवीएस का उपयोग किया, लेकिन मैंने तुरंत एक ही राय बनाई। स्क्रैच से शुरू करते समय हमने एसवीएन का इस्तेमाल किया और इसे पाया, जबकि सही नहीं, अभी भी काफी बेहतर है। –
सीवीएस के साथ मेरी सबसे बड़ी समस्या यह है कि काम परमाणु होने की गारंटी नहीं है। बहुत हीलिरिटी आती है। बस एक आधुनिक वीसीएस का उपयोग करें ... एसवीएन ज्यादातर उद्देश्यों के लिए बहुत अच्छा है। – rmeador
सीवीएस में प्रतिबद्धताएं उसी निर्देशिका में "परमाणु" हैं (लॉकिंग के कारण) लेकिन बाहर नहीं। हाल के संस्करण (1.12) में आरसीएस फ़ाइल में एक प्रतिबद्ध आईडी संग्रहित है लेकिन यह अभी भी एक हैक है। – Keltia