एसवीएन: परियोजनाओं में सामान्य कोड साझा करने का सबसे अच्छा तरीका

Question

मेरे पास एक ही रिपोजिटरी में एकाधिक वेबसाइट प्रोजेक्ट हैं जिनमें से प्रत्येक में वर्डप्रेस की एक प्रति है। वर्डप्रेस अपडेट करना मतलब है कि सभी प्रोजेक्ट फ़ोल्डरों को अपडेट करना और अनावश्यक प्रतियां रखना। यह मेरी rsync स्क्रिप्ट के लिए उपयोगी है जो पूरे फ़ोल्डर को सिंक करता है। यह मुझे साइट की पूरी तरह से स्थानीय प्रतियां भी देता है।

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

1. प्रत्येक वेबसाइट फ़ोल्डर में वर्डप्रेस बिट्स के प्रतीकात्मक लिंक बनाएं। क्या यह सबवर्जन और अपाचे में होगा। कोई कमी?
2. एक वर्डप्रेस फ़ोल्डर है और इसे अन्य वेबसाइट ट्रंक में ब्रांच करें। मैंने पढ़ा है कि शाखाएं सस्ता हैं और एक प्रतिलिपि बनाए रखा गया है लेकिन मुझे यकीन नहीं है कि शाखाओं में शाखाओं को पूरा किया जाना चाहिए। व्यक्तिगत रूप से, मुझे लगता है कि यह सबसे अच्छा तरीका है। क्या इससे बचने का कोई कारण है?
3. आखिरकार, मैं वर्तमान संरचना को रख सकता हूं और सभी वेबसाइट फ़ोल्डरों में प्रतिलिपि बनाने के लिए एक स्क्रिप्ट का उपयोग कर सकता हूं।

सबसे अच्छा तरीका क्या है और क्या कोई वैकल्पिक समाधान है?

Answer 1

एक विकल्प वर्डप्रेस बिट्स को एक अलग भंडार में अलग करना होगा (क्योंकि यह वास्तव में आपकी परियोजनाओं का हिस्सा नहीं है, यह केवल कुछ है जो आप उन्हें बनाने के लिए उपयोग करते हैं), और फिर अपनी परियोजनाओं में लाने के लिए svn: externals का उपयोग करें सही स्थानों में।

Externals Definitions in the SVN book

Answer 2

आप WordPress repository करने के लिए एक svn:external परिभाषा की ओर इशारा करते जोड़ सकते हैं या प्लग इन और अनुकूलन आप का उपयोग के साथ अपने स्वयं अलग "अनुकूलित वर्डप्रेस भंडार" बना सकता है।

Answer 3

हो सकता है कि मैं सिर्फ सबवर्सन गलत तरीके से उपयोग कर रहा हूँ, लेकिन जैसे निम्नलिखित हमारी फ़ोल्डर संरचना लग रहा है

ट्रंक - कोर - मैसेजिंग - सुपर शक्तिशाली # 1 आवेदन - सुपर शक्तिशाली आवेदन # 2 - सुपर शक्तिशाली एप्लिकेशन # 3

तो हमारे सभी ऐप्स समान कोर और संदेश घटक साझा करते हैं। इसका एकमात्र नकारात्मक पक्ष यह है कि जब लोग शाखा करते हैं, तो वे सभी आवेदन प्राप्त करते हैं, लेकिन किसी भी चीज़ से ज्यादा परेशानियां होती हैं।

Answer 4

अक्सर मुझे विभिन्न परियोजनाओं के लिए एक ही कक्षा पुस्तकालयों का पुन: उपयोग करना पड़ता है और मेरे मामले में मैं प्रत्येक परियोजना के लिए अलग-अलग-प्रति-प्रतिलिपि रखना पसंद करता हूं। एकमात्र कारण यह है कि मैं परियोजनाओं को तोड़ना नहीं चाहता हूं, अगर पुस्तकालयों में से कोई एक इसे पुराना करता है तो मैंने थोड़ी देर तक काम नहीं किया है। हालांकि यदि प्रत्येक परियोजना एक मुख्य परियोजना का एक हिस्सा है, तो आप लगातार इसके अलग-अलग काम कर रहे हैं।

Answer 5

ऐसा करने का एक बेहतर तरीका है कि आप अपने भंडार की एक अलग शाखा में वर्डप्रेस खींचें। फिर, अपनी वेबसाइटों में से प्रत्येक को कॉन्फ़िगरेशन फ़ाइल प्रस्तुत करें जो Wordpress के पथ को संग्रहीत करता है। आप इस स्थान को अपने php में जोड़ सकते हैं पथ शामिल करें। यहाँ एक चित्र है:

• आप एक बार में Wordpress के कई संस्करण के साथ प्रयोग के परीक्षण और क्या-नहीं ऐसा करने के लिए कर सकते हैं:

  यह फायदे की एक जोड़ी है।आप इन सभी वेबसाइटों के बीच साझा कर सकते हैं

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

Answer 6

परंपरागत रूप से सब कुछ एसवीएन पर अलग किया जाना चाहिए। ऐसा लगता है कि आप विभिन्न क्षेत्रों से कोड पकड़ने और उन्हें एक साथ सिलाई करने के साधन के रूप में एसवीएन का उपयोग कर रहे हैं।

तो आप बिल्ड-टूल के रूप में एसवीएन का उपयोग कर रहे हैं। यह बेहतर है:

• रखने अपने प्लग-इन को अलग
• SVN में वर्डप्रेस ही स्टोर नहीं करते, जब तक आप एक विक्रेता शाखा
• का उपयोग करके ऐसी विशिष्ट घटकों, एक साथ काम के साथ किसी विशिष्ट एप्लिकेशन हड़पने के लिए की जरूरत है निर्माण स्क्रिप्ट।

Answer 7

यदि आप पहले से ही एक ही भंडार में सभी साइटों को होस्ट कर रहे हैं, तो svn: बाहरीों को एक ही भंडार के विभिन्न हिस्सों को एक साथ विभिन्न तरीकों से खींचने के लिए उपयोग किया जा सकता है।

उदा। जैसे

 
repo/site1 
repo/site2 
repo/commonPieces 

भंडार के साथ आपको एक "SVN: बाहरी" लागू कर सकते हैं site1 और site2 dirs कि कहते हैं, "commonPieces यूआरएल करने वाली रेपो/commonPieces" पर संपत्ति।

आप यहां स्पष्ट रूप से किसी भी रिकर्सन लूप से बचना चाहते हैं। लेकिन इसका लाभ यह है कि सबकुछ एक ही भंडार में है और इतिहास साझा कर सकता है - आप उन चीज़ों को खींच सकते हैं जो साइट 1 या साइट 2 से "svn copy" का उपयोग करके आम टुकड़ों में अधिक आम हो रहे हैं।

हमारे वर्तमान समाधान मैं कहाँ काम कर रहा हूँ की तुलना करें - एक भी भी-अलग "coreLibraries" भंडार में हमारे अलग परियोजना खजाने से सामान पलायन विकास इतिहास खो देता है। जब से हम आम तौर पर एक परियोजना के लिए सुविधाओं को विकसित करने और उसके बाद करने के लिए उन्हें फिर से उपयोग निर्णय लेते हैं, इतिहास की इस हानि होता है एक बहुत ...

---

संपादित करें: यह याद रखने लायक है, जबकि site1 पर "SVN अद्यतन" आप अपडेट हो जाएगा कि साइट पर इस "svn: externals" संपत्ति के साथ आम टुकड़े, साइट 1 पर "svn प्रतिबद्ध" साइट 1/सामान्य टुकड़ों में बदल गई चीज़ों को नहीं दिखाएगा। आपको दो अलग-अलग काम करना होगा, साइट 1 से एक और साइट 1/कॉमनपीस से एक।

Answer 8

सबसे अच्छा तरीका क्या है और क्या कोई वैकल्पिक समाधान है?

विषय बंद होने के लिए नहीं है, लेकिन मैं सुझाव है कि आप एक कठिन submodules साथ में git. पर नज़र हम बात दिन के इस प्रकार करते हैं और दिन बाहर ले, और यह एक हवा है।

एफवाईआई - इस प्रकार के मुद्दों के कारण 2 साल पहले एसवीएन से माइग्रेट किया गया था।