2012-01-16 14 views
5

में किसी प्रोजेक्ट के दो संस्करणों के साथ काम करने के लिए वर्कफ़्लो मेरे पास एक ऐसा एप्लिकेशन है जो संस्करण 1.0 है। अब मुझे संस्करण 2.0 पर काम शुरू करने की आवश्यकता है, लेकिन साथ ही संस्करण 1.0 में बग को बनाए रखें और ठीक करें।Mercurial

1.0 से

बग सुधार 2.0 रिहाई में मिल जाएँगे, लेकिन कोई नई कार्यक्षमता 2.01.0 को रिलीज से बैकपोर्टेड किया जाएगा।

मैं समझता हूं कि शाखाएं कैसे काम करती हैं, हालांकि मुझे एक ही समय में दोनों संस्करणों पर काम करने में सक्षम होना चाहिए ताकि एक ही काम करने वाले फ़ोल्डर में शाखाओं के बीच स्विचिंग व्यावहारिक न हो। मैं एक ही समय में कोड के दोनों संस्करणों को चलाने में सक्षम होना चाहता हूं।

एक ही समय में नामित शाखाओं का उपयोग करके उसी एप्लिकेशन के दो संस्करणों पर काम करने में सक्षम होने के लिए एक सामान्य सेटअप या वर्कफ़्लो क्या है? यानी एक शाखा में एक शाखा के साथ काम करना और किसी अन्य फ़ोल्डर में दूसरी शाखा?

क्या मैं सिर्फ 2.0 के लिए एक नए फ़ोल्डर में भंडार क्लोन करता हूं और शाखा को 2.0 रिलीज़ के लिए सेट करता हूं?

मैं Mercurial के लिए थोड़ा नया हूँ इसलिए कृपया मुझे क्षमा करें अगर यह थोड़ा सा बेवकूफ लगता है।

+1

आज़माएं: http://nvie.com/posts/a-sccessful-git-branching-model/ इसका उद्देश्य जीआईटी के लिए है, लेकिन Mercurial के लिए काम करता है। यह आपकी समस्या – PostMan

+0

में मदद कर सकता है जैसा कि आप सुझाव देते हैं: कोड के दो चेक आउट (क्लोन) संस्करण हैं, एक संस्करण 1.0 के लिए और संस्करण 2.0 के लिए एक है। –

उत्तर

7

क्या मैं सिर्फ संस्करण 2.0 के लिए एक नए फ़ोल्डर में भंडार क्लोन करता हूं और 2.0 रिलीज के लिए शाखा को सेट करता हूं?

हां, प्रत्येक प्रमुख रिलीज के लिए एक अलग क्लोन ठीक होगा। हालांकि, आपको अपना मुख्य विकास on the default branch रखना चाहिए और प्रत्येक प्रमुख रिलीज के लिए नामित शाखाओं का उपयोग करना चाहिए। मुझे कार्यप्रवाह के माध्यम से चलते हैं:

जब आपके संस्करण 1.0 से किया जाता है, है न

$ cd ~/src/foo 
$ hg tag 1.0 
$ hg push http://your-server/foo 

और आप तो संस्करण 2.0 की ओर है कि क्लोन में काम जारी रख सकते हैं। जब आप पाते हैं कि आप 1.0 में एक बग को ठीक करने की जरूरत है, तो आप

$ cd ~/src 
$ hg clone http://your-server/foo foo-1.x 
$ cd foo-1.x 
$ hg update 1.0 
$ hg branch 1.x 
$ hg commit -m "Starting 1.x branch" 
# now fix the bug... left as an exercise to the reader :) 
$ hg commit -m "Fixed issue123" 
# do QA to test the bugfix, make more commits as necessary 
$ hg tag 1.1 
$ hg push --new-branch 
# make a release 

--new-branch झंडा केवल पहली बार कोई धक्का आवश्यक है। यह Mercurial बताता है कि आप वास्तव में इतिहास में एक नई स्थायी शाखा बनाना चाहते हैं।

अब आप अन्य भंडार में बग सुधार खींचने के लिए चाहते हैं:

$ cd ~/src/foo 
$ hg pull http://your-server/foo 
$ hg merge 1.x 
$ hg commit -m "Merge with 1.1" 

1.x श्रृंखला के लिए एक named branch का उपयोग करके आप हमेशा hg update 1.x का उपयोग करने वाले शाखा पर नवीनतम changeset पर जाने के लिए कर सकते हैं। 1.x को "फ़्लोटिंग टैग" के रूप में सोचें जो हमेशा उस शाखा पर टिप-सबसे अधिक परिवर्तन को इंगित करता है।

यह वर्कफ़्लो standard branching wiki page में वर्णित है।

+1

+1। संभावित रूप से ध्यान देने योग्य है कि डिफ़ॉल्ट Mercurial में, मुझे लगता है कि आपको 1.x शाखा से पुश को मजबूर करने के लिए 'hg push -f' की आवश्यकता होगी ... क्योंकि आप एक नया सिर दबाएंगे, जो "मजबूर" के बिना स्वीकार्य नहीं है ।एक ही विकास रेखा में, अतिरिक्त सिर को आम तौर पर विलय करके ख्याल रखा जाएगा, लेकिन यह वही नहीं है जो यहां चाहता था। – icabod

+1

@icabod: धन्यवाद, मैं '- न्यू-शाखा 'ध्वज के बारे में भूल गया था। यह '-f' का एक अधिक नियंत्रित रूप है जो आपको कई शाखाओं को धक्का देने के बिना नई शाखाओं को धक्का देता है। –

+1

आह, मैं पहले 'एनन-शाखा' का उपयोग नहीं करता था, संभवतः क्योंकि मुझे अज्ञात शाखाएं बनाने की परेशानी की आदत है, जिसके लिए '- नई शाखा' काम नहीं कर रही है। 'नामित शाखाओं के लिए अच्छा है'। मैं भविष्य में इसका उपयोग करूंगा :) – icabod