मेरे पास अलग-अलग परियोजनाएं हैंमेरी एसवीएन रिपॉजिटरी में बैठे साइकल जारी करें। एसवीएन में क्लासिक टैग संरचना का उपयोग करके राहतें बनाई जाती हैं। जब रिलीज़ में फिक्स करने के लिए कीड़े होते हैं तो एक टैग से एक शाखा बनाई जाती है, बग को ठीक किया जाता है और फिर वहां से ट्रंक में विलय कर दिया जाता है।
अब, कई कारणों से, मैं केंद्रीय पुश साइट के साथ एसवीएन से मर्क्यूरियल में स्विच करना चाहता हूं।
प्रश्न: कई परियोजनाओं को व्यवस्थित करने का सबसे अच्छा तरीका क्या है जो उन दोनों के बीच थोड़ा सा कोड साझा करता है? क्या मुझे प्रत्येक परियोजना के लिए एक से अधिक पुश साइटें बनानी चाहिए?
कृपया मेरे उत्तर-टैग, बगफिक्स ब्रांच, ... को रिपॉजिटरी डिज़ाइन के अपने पसंदीदा संस्करण के साथ कैसे पुनः बनाएँ, इस पर एक विवरण शामिल करें।
संपादित करें: मैं संभव के रूप में छोटे एक्सटेंशन स्थापित करना चाहूंगा।
EDIT2:
इस SVN लेआउट को देखते हुए:
.
|-- project-a
| |-- branches
| | |-- 1.x
| | `-- feature-1
| |-- tags
| `-- trunk
`-- project-b
|-- branches
|-- tags
| |-- 1.0
| `-- 1.1
`-- trunk
(साभार @ बेंडिन! :))
क्या कई hg पुश रिपॉजिटरी के साथ काम करना बेहतर है
project_a-trunk
project_a-1.x
project_a-feature-1
project_b-trunk
शाखाओं के लिए। टैग को उपयुक्त शाखा में जोड़ दिया जाता है।
या आप इस उदाहरण में दो पुश रिपॉजिटरी के साथ जाएंगे
project_a
project_b
एक रेपो के भीतर नामित शाखाओं और इसलिए कई सिर हैं।
लाभ मैं कई प्रमुख प्रतिनिधि के साथ देखता हूंक्या यह है कि मुझे कई रिपॉजिट में टैग के लिए शिकार करने नहीं जाना पड़ता है। मुझे जो नुकसान होता है वह यह है कि hg बुक कई हेड रिपोज को हतोत्साहित करती है। आप क्या करेंगे / क्या करेंगे?
उत्तर:
उत्तर № 1 के लिए 12कुछ तोड़फोड़ करने वाली रिपॉजिटरी एक ट्रंक के तहत तार्किक रूप से असंबंधित चीजों (जैसे विभिन्न संस्करण संख्या और रिलीज चक्र) के साथ समूह बनाएगी:
.
|-- branches
| |-- project-a-1.x
| `-- project-a-feature-1
|-- tags
| |-- project-a-1.0
| |-- project-b-1.0
| `-- project-b-1.1
`-- trunk
|-- project-a
`-- project-b
इस तरह के लेआउट का मर्क्यूरियल में कोई सीधा एनालॉग नहीं है। प्रत्येक परियोजना जिसका अपना रिलीज़ चक्र और स्वयं का संस्करण संख्याएँ हैं, का अपना भंडार होना चाहिए।
कुछ तोड़फोड़ करने वाले रिपॉजिटरी को प्रत्येक परियोजना को अपनी ट्रंक, टैग और शाखाएं देने के लिए संरचित किया जाता है:
.
|-- project-a
| |-- branches
| | |-- 1.x
| | `-- feature-1
| |-- tags
| `-- trunk
`-- project-b
|-- branches
|-- tags
| |-- 1.0
| `-- 1.1
`-- trunk
आप प्रत्येक प्रोजेक्ट को तार्किक मान सकते हैंआपके भौतिक तोड़फोड़ भंडार के भीतर भंडार। प्रत्येक प्रोजेक्ट की अपनी ट्रंक, टैग और शाखाएँ होती हैं। इसका यह भी लाभ है कि आप टैग और शाखा नामों को छोटा रख सकते हैं क्योंकि आप पहले से ही जानते हैं कि वे किस परियोजना से संबंधित हैं।
यह लेआउट मर्क्यूरियल जैसे टूल के साथ व्यक्त करने के लिए भी तुच्छ है। प्रत्येक "प्रोजेक्ट" एक व्यापारिक भंडार बन जाता है। उस भंडार के भीतर टैग और शाखाएँ उस परियोजना के टैग और शाखाएँ हैं।
जवाब के लिए 8 № 2
जैसा कि बेंडिन कहता है, आपको एक शुरुआत के रूप में प्रत्येक स्वतंत्र परियोजना के लिए कई रिपॉजिटरी बनाना चाहिए।
मरकरी कमिट्स को रिपॉजिटरी-वाइड बनाया जाता हैस्तर और आप केवल एक उपनिर्देशिका की जांच नहीं कर सकते। यह सबवर्सन के विपरीत है जो आपको केवल कुछ फ़ाइलों को शुरू करके इन-सुसंगत कमिट करने की अनुमति देता है, लेकिन फिर यह आपको केवल एक उपनिर्देशिका की जांच करने की भी अनुमति देता है।
जब आप एक रिलीज़ करते हैं तो आप आम तौर पर अपने मर्क्यूरियल रिपॉजिटरी में एक टैग जोड़ते हैं (hg tag)। आप स्वतंत्र रूप से तय कर सकते हैं कि क्या आप प्रत्येक रिलीज के लिए बगफिक्स रिपॉजिटरी रखना चाहते हैं, यदि आप पहली बार जरूरत होने पर उन्हें बनाना चाहते हैं। चाल है कि
% hg क्लोन -r 1.0 प्रोजेक्ट-ए प्रोजेक्ट-ए-1.0.x
एक रिपॉजिटरी बनाने के लिए इस्तेमाल किया जा सकता है project-a-1.0.x जो केवल टैग तक का इतिहास रखता है 1.0। फिर आप बग को ठीक कर सकते हैं project-a-1.0.x और इसे पीछे धकेलें project-a। इसके अलावा बगफिक्स को बनाया जा सकता है project-a-1.0.x भंडार।
जवाब के लिए 2 № 3
मुझे लगता है कि आप कोशिश करना चाहते हैं मरुस्थलीय वन विस्तार