क्या आपके पास छोटी परियोजनाओं के लिए शाखा, टैग और ट्रंक फ़ोल्डर्स भी होनी चाहिए?


7

मेरे पास एसवीएन में छोटी और बड़ी परियोजनाओं का मिश्रण है। उनमें से कुछ इतने छोटे हैं कि मैं खुद को ब्रांचिंग या टैगिंग की पूर्ववत नहीं कर सकता।

तो, क्या मुझे अभी भी ट्रंक/शाखा/टैग फ़ोल्डर सम्मेलन के साथ रहना चाहिए, भले ही मैं निश्चित रूप से शाखाओं/टैग निर्देशिकाओं को छोटी परियोजनाओं के लिए उपयोग नहीं करूँ? मुझे लगता है कि यह अधिक हो सकता है।

इस पर विचार?

  0

@किंगनेस्टर, जो आप पूछ रहे हैं उससे थोड़ा बेहतर प्रतिबिंबित करने के लिए अपना शीर्षक संपादित किया। अच्छा सवाल हालांकि! 22 feb. 092009-02-22 06:33:24

19

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

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

+1

बेशक, एसवीएन में तथ्य के बाद निर्देशिकाओं को स्थानांतरित करना आसान है। इसलिए, यदि आप उन्हें अभी नहीं डालते हैं और निर्णय लेते हैं कि आपको बाद में उनकी आवश्यकता है, तो यह वास्तव में एक विशेष रूप से बड़ा सौदा नहीं है। 14 may. 092009-05-14 20:42:22


2

वे सम्मेलन हैं, इसलिए उन्हें जोड़ने के लिए क्या नुकसान होता है। यदि आपकी परियोजना उस बिंदु पर पहुंच जाती है जहां आपको उनकी आवश्यकता होती है, तो शुरुआत के बाद उन्हें वास्तविकता में रखना बहुत आसान है।


6

मैं छोटी परियोजनाओं के लिए भी subversion में शाखा/टैग/ट्रंक निर्देशिका का उपयोग करता हूं। यह काफी शून्य लागत है और स्थिरता में इसके लायक है। मुझे हमेशा पता है कि अगर मुझे कभी भी चेकआउट करने की ज़रूरत है तो मेरी परियोजना कैसे निर्धारित की जा रही है।


0

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

यहां तक ​​कि निजी परियोजनाओं को प्रमुख पुनर्लेखन या लंबे अंतराल के बाद कम से कम टैगिंग और ब्रांचिंग से लाभ हो सकता है।


0

आमतौर पर (या स्पष्ट रूप से), शाखाओं/टैगिंग टीमों में बेहद उपयोगी हैं, जहां कई कोडर एक ही समय में स्रोत के साथ काम करेंगे। प्रत्येक कोडर अपनी शाखा में काम करता है इसलिए किसी और के काम को बचाने का कोई खतरा नहीं है।

एक व्यक्ति सेना डेवलपर के रूप में, मैं अभी भी शाखाओं में मिल गया है/उपयोगी टैगिंग जब:

  1. मैं वर्तमान कार्यशील स्रोत पर देने के बिना एक प्रायोगिक शाखा बनाने की जरूरत है। यदि प्रयोगात्मक कोड बेहतर साबित होता है तो मैं इसे वापस विलय कर दूंगा।

  2. यदि मेरे पास कई अलग-अलग घटक हैं, तो प्रत्येक व्यक्ति को प्रोजेक्ट संस्करण संख्या को नाम देने वाले नाम के साथ टैग करना और प्रोजेक्ट के नाम पर टैग टैग में डाल देना उपयोगी हो सकता है। यह टैब को रखने में मदद करता है जब आप संस्करण 1.0.5.10 पर वापस जाना चाहते हैं और यह जानने की आवश्यकता है कि घटक Foo में क्या बदला गया है। प्रतिबद्ध नोट पर्याप्त जानकारीपूर्ण नहीं हो सकता है।


0

मेरे अनुभव में, 'ट्रंक/शाखा/टैग' संगठन स्रोत नियंत्रण के लिए एक बहुत अच्छी तरह से उपयोग किया जाने वाला लेआउट है। मैंने इसे विभिन्न उपकरणों (क्लीयरकेस, एसवीएन, सीवीएस, कुछ नाम देने के लिए) का उपयोग करके कई अलग-अलग संगठनों में लागू किया है। क्लीयरकेस सेटअप जो मैं वर्तमान में काम करता हूं वह थोड़ा अधिक परिष्कृत (संकलित?) है, लेकिन आम तौर पर बोलते हुए, एक बहुत ही समान लेआउट का पालन किया जाता है।

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

व्यक्तिगत परियोजनाओं के लिए, मुझे टैगिंग को अंतिम, अपरिवर्तनीय रिलीज को संरक्षित करने का एक मूल्यवान माध्यम माना जाता है। शाखाएं आम तौर पर प्रयोगात्मक स्पर्शकों के लिए आरक्षित होती हैं, इसलिए मैं वास्तविकता में आने से पहले अपने कोड के सबसे हालिया (स्थिर) संस्करण को नष्ट नहीं करूंगा।