2010-05-17 7 views
7

मेरे पास कई अलग-अलग ग्राहकों के लिए कुछ एएनटी परियोजनाएं हैं; निर्देशिका संरचना अपनी परियोजनाओं के लिए मेरे पास है इस तरह दिखता है:Mercurial और ग्रहण के साथ परियोजना फ़ीचर उप मॉड्यूल के लिए सर्वोत्तम अभ्यास?

L___standard_workspace 
    L___.hg 
    L___validation_commons-sub-proj <- JS Library/Module 
    | L___java 
    | | L___jar 
    | L___old_stuff 
    | L___src 
    | | L___css 
    | | L___js 
    | |  L___validation_commons 
    | L___src-test 
    |  L___js 
    L___v_file_attachment-sub-proj <- JS Library/Module 
    | L___java 
    | | L___jar 
    | L___src 
    | | L___css 
    | | L___js 
    | L___src-test 
    |  L___js 
    L___z_business_logic-sub-proj <- JS Library/Module 
    | L___java 
    | | L___jar 
    | L___src 
    |  L___css 
    |  L___js 
    L____master-proj    <- Master web-deployment module where js libraries are compiled to. 
     L___docs 
     L___java 
     | L___jar 
     | L___src 
     |  L___AntTasks 
     |   L___build 
     |   | L___classes 
     |   |  L___com 
     |   |   L___company 
     |   L___dist 
     |   L___nbproject 
     |   | L___private 
     |   L___src 
     |    L___com 
     |     L___company 
     L___remoteConfig 
     L___src 
     | L___css 
     | | L___blueprint 
     | | | L___plugins 
     | | | | L___buttons 
     | | | | | L___icons 
     | | | | L___fancy-type 
     | | | | L___link-icons 
     | | | | | L___icons 
     | | | | L___rtl 
     | | | L___src 
     | | L___jsmvc 
     | L___img 
     | | L___background-shadows 
     | | L___banners 
     | | L___menu 
     | L___js 
     | | L___approve 
     | | L___cart 
     | | L___confirm 
     | | L___history 
     | | L___jsmvc 
     | | L___mixed 
     | | L___office 
     | L___stylesheets 
     | L___swf 
     L___src-standard 

काम करने के भीतर नकल मॉड्यूल संकलन एक भी जावास्क्रिप्ट फ़ाइल है कि मास्टर परियोजना के जावास्क्रिप्ट निर्देशिका में रखा गया है में उप-परियोजना।

उदाहरण के लिए, निर्देशिका:

  • validation_commons-sub-proj
  • v_file_attachment-sub-proj
  • z_business_logic-sub-proj

... सभी संयुक्त और न्यूनतम किया जाता है (जैसे संकलित की तरह) एक अलग में _master-proj/js निर्देशिका में जावास्क्रिप्ट फ़ाइल नाम; और अंतिम चरण में _master-proj को सर्वर पर तैनात करने के लिए संकलित किया गया है।

अब जिस तरह से मैं इसे एचजी के साथ सेट करना चाहता हूं, मैं जो करना चाहता हूं वह मास्टर प्रोजेक्ट और इसकी उप-परियोजनाओं को अपने स्वयं के बेस-लाइन रिपॉजिटरीज़ से क्लोन कर रहा है ग्राहक की कार्य-प्रतिलिपि, ताकि मॉड्यूल को किसी विशेष ग्राहक की कार्यशील प्रति में जोड़ा जा सके (एचजी का उपयोग कर)।

इसके अतिरिक्त, जब मैं एक ग्राहक की कामकाजी प्रति में बग में कुछ बदलाव/फिक्स करता हूं, तो मैं वैकल्पिक रूप से परिवर्तन/बग फिक्स को मास्टर प्रोजेक्ट/सब-प्रोजेक्ट के बेस-लाइन रेपॉजिटरी में वैकल्पिक रूप से धक्का दे सकता हूं , आखिरकार अन्य ग्राहक की कामकाजी प्रतियों में परिवर्तन/फिक्स को खींचने के प्रयोजनों के लिए, जिसमें वही बग शामिल हो सकते हैं जिन्हें ठीक करने की आवश्यकता है।

इस तरह से मैं अलग-अलग ग्राहकों में एक ही बग फिक्स का उपयोग करने में सक्षम हूं।

हालांकि ... मैं एचजी और ग्रहण का उपयोग करके ऐसा करने का सबसे अच्छा तरीका अनिश्चित हूं।

I कि आप --filemap विकल्प का उपयोग कर एक उप-निर्देशिका को एक अलग-अलग प्रोजेक्ट में विभाजित करने के लिए एचजी के Convert Extension का उपयोग कर सकते हैं।

हालांकि, मैं अभी भी थोड़ा उलझन में हूं कि Convert Extension का उपयोग करना बेहतर होगा या यदि यह अपने स्वयं के भंडार में प्रत्येक मॉड्यूल को बस घर में रखना बेहतर होगा और उन्हें एक एकल कार्यक्षेत्र में जांचना बेहतर होगा प्रत्येक ग्राहक के लिए।

+0

क्या इस क्रिया के लिए संक्षिप्त संक्षिप्त नाम है कि मैं यहां व्याख्या/प्रदर्शन करने का प्रयास कर रहा हूं? – leeand00

+0

मुझे लगता है कि इस पर उलझन में एक और जगह यह होगी कि मैं एक अलग भंडार में पूरी चीज़ को शामिल किए बिना, अपने व्यक्तिगत भंडारों से मुझे सही विशिष्ट मॉड्यूल की जांच कैसे कर सकता हूं? – leeand00

+1

मुझे लगता है कि मुझे शायद यहां जवाब मिल गया: http://mercurial.selenic.com/wiki/subrepos – leeand00

उत्तर

3

हाँ, यह subrepos तरह लग रहा है आप के लिए क्या देख रहे हैं, लेकिन मुझे लगता है कि हो सकता है कि गलत प्रश्न के लिए सही जवाब है और मैं दृढ़ता से संदेह है कि आप इसी तरह issues that occur when using svn:externals

में चलाने इसके बजाय मैं सिफारिश करेंगे कि आप अपनी संयुक्त और minified जेएस फ़ाइलों को artefact repository पर "प्रकाशित" करते हैं और अपने मास्टर प्रोजेक्ट में अपने कलाकृतियों के विशिष्ट संस्करणों को खींचने के लिए Ivy जैसे निर्भरता प्रबंधक का उपयोग करते हैं। यह दृष्टिकोण आपको आपके मास्टर प्रोजेक्ट के उप-प्रोजेक्ट संस्करणों पर बहुत अधिक नियंत्रण प्रदान करता है।

यदि आपको किसी विशेष ग्राहक के लिए उप-प्रोजेक्ट में बग फिक्स करने की आवश्यकता है, तो आप केवल उस उप-प्रोजेक्ट के लिए मुख्य लाइन पर फ़िक्सेस बना सकते हैं, एक नया संस्करण प्रकाशित कर सकते हैं (आदर्श रूप से automated build pipeline के माध्यम से) और अपने मास्टर को अपडेट करें नए संस्करण का उपयोग करने के लिए परियोजना। ओह, आप प्रकाशन से पहले अपने मास्टर प्रोजेक्ट के साथ नए संस्करण का परीक्षण करना चाहते थे?उस स्थिति में, अपने फिक्स को धक्का देने से पहले, स्थानीय रूप से अपने उप-प्रोजेक्ट को गठबंधन और छोटा करें, इसे local repository पर प्रकाशित करें और ग्राहक के मास्टर प्रोजेक्ट को आपके परीक्षण के लिए उस संस्करण को उठाएं।

संबंधित मुद्दे