सबवर्सन: क्या एकाधिक प्रतिलिपि एक ही संशोधन में किया जा सकता है?

Question

मैं क्या लेन-देन सबवर्सन में इस सिद्धांत में संभव हो जाना चाहिए के बारे में समझते हैं, लेकिन मैं किसी भी उपकरण है कि यह समर्थन करता है, पता नहीं है से।

पृष्ठभूमि है कि हम सबवर्सन को PVCs आयाम से एक प्रवास चर्चा कर रहे हैं, और सबवर्सन में लापता के रूप में उद्धृत मुख्य विशेषता "डिजाइन पार्ट्स" है। एक डिज़ाइन हिस्सा फाइलों का एक मनमाना संग्रह है जिसे एक साथ संभाला जा सकता है, उदा। सबप्रोजेक्ट के लिए आवश्यक सभी स्रोत फ़ाइलें।

एक विचार यह बदलने के लिए एक Makefile में कॉपी ऑपरेशन है, जो एक शाखा में प्रासंगिक फ़ाइलों की प्रतिलिपि कर रहा है। लेकिन अगर सभी फाइलें अलग-अलग कॉपी की जाती हैं तो इससे कई संशोधन हो सकते हैं, जो इतिहास को अव्यवस्थित कर सकते हैं, इसलिए इससे बचना अच्छा लगेगा।

संपादित करें: कुछ अधिक पृष्ठभूमि जानकारी:

परियोजना जो अलग से जारी कर रहे हैं कई (5-10) उप के होते हैं, लेकिन जो कुछ आम स्रोत फ़ाइलों और बाहरी अन्य परियोजनाओं से आयातित पुस्तकालयों को साझा करें।

डिज़ाइन भागों के लिए उद्धृत एक कारण स्रोत फ़ाइलों पर निर्भरता को प्रतिबंधित कर रहा है, दूसरा सबप्रोजेक्ट के उत्पादों के प्रबंधन के लिए है, ताकि उन सभी को एक ऑपरेशन में संस्करण नियंत्रण में अपडेट किया जा सके। दोनों प्रकार की फाइलें निर्देशिकाओं में कुछ हद तक छिड़कती हैं।

हम इस परियोजना पर लगभग 5 डेवलपर्स रहे हैं।

Answer 1

आप एक काम की नकल में प्रतियां बनाने और उन्हें एक बार बाद में पर प्रतिबद्ध कर सकते हैं। यह केवल एक संशोधन बनाता है।

कमांड लाइन ग्राहक यह है कि ऐसा दिखाई दे सकता है:

svn copy file1 directory 
svn copy file2 directory 
svn copy file3 directory 
svn commit 

मुख्य नकारात्मक पक्ष यह है कि आप एक काम की नकल करते हैं और इस काम की नकल की जरूरत है स्रोत और लक्ष्य-निर्देशिका शामिल करने के लिए है।

Answer 2

क्यों आप एक खुद उपनिर्देशिका में अपने subproject न रखें।

Project 
    | 
    ---> Subproject 1 
    ---> Subproject 2 
    Files from project. 

इस तरह आप हमेशा एक पूर्ण सबप्रोजेक्ट पर काम कर सकते हैं।

यहाँ हम है:

Project 
    | 
    ---> common Files 
    ---> Subprojects... 

Answer 3

तो सभी परियोजनाओं को अपने स्वयं के खजाने में थे, SVN बाहरी चाल

Answer 4

ऐसा कर सकते हैं वहाँ एक उपकरण svnmucc जो वास्तव में इस करता है, एक काम की नकल की आवश्यकता के बिना है:

http://subversion.tigris.org/tools_contrib.html#svnmucc_c

Answer 5

यह काफी दिलचस्प, मैं सिर्फ, डिजाइन भागों पर एक त्वरित पढ़ा था कि मैं क्या इकट्ठा कर सकते हैं से, के द्वारा होता है फाइलों को व्यक्तिगत रूप से एक मनमानी संरचना में प्रभावी ढंग से ब्रांच करना, जब आप चीज़ों को अपने मूल स्थान पर वापस विलय करना शुरू करते हैं तो आप दर्द की दुनिया के लिए आगे बढ़ने जा रहे हैं (और विलय शायद सभी में एक ही प्रतिबद्धता में नहीं किया जाएगा फ़ाइलें)।

लेकिन मुझे लगता है आप फेरबदल का एक सा के साथ तोड़फोड़ में भागों डिजाइन करने के लिए एक ऐसी ही बात कर सकते हैं:

सबसे पहले, एक डिजाइन हिस्सा बाहरी (1.6 बाहरी निर्देशिका के रूप में फाइल को इंगित करने की भी अनुमति देता का उपयोग कर नकली किया जा सकता है)। ऐसा करने के लिए, आप सेटअप सकता है इस तरह अपनी परियोजना पदानुक्रम:

/project1 
/trunk 
    /doc 
    /design1 
    /release2 
    /src 
    /subproject1 
    /subproject2 
/tags 
/branches 
/parts 
    /part1 
    /part2 
    /part3 

प्रत्येक भागों फ़ोल्डर केवल एक "SVN: बाहरी" होते हैं संपत्ति जो उचित sublocation, जैसे कि भाग के लिए उचित फाइलों में लाता है:

svn:externals 

../../trunk/src/subproject1  src/subproject1 
../../trunk/doc/release2   doc/release2 

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

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

भागों की परिभाषा का प्रबंधन करना अधिक दिलचस्प हो जाता है, क्योंकि ऊपर की योजना में, प्रत्येक भाग मैन्युअल रूप से परिभाषित किया जाता है और वे पदानुक्रमित नहीं होते हैं। आपको कुछ प्रकार की स्क्रिप्ट (शायद मेकफ़ाइल) की आवश्यकता होगी जो भागों पदानुक्रम को जानता है और एक भाग नाम दिया गया है, उचित बाहरी परिभाषाओं का निर्माण कर सकता है जिसे तब भागों की निर्देशिका में लागू किया जा सकता है।

इसलिए जब विवर्तन स्पष्ट रूप से भागों की अमूर्त परत प्रदान नहीं करता है, तो इसे मैन्युअल रूप से काफी सटीक रूप से मॉडलिंग किया जा सकता है - आप केवल svn: बाहरी और स्क्रिप्ट्स की क्षमताओं से सीमित हैं जिनका उपयोग आप उन्हें प्रबंधित करने के लिए करते हैं।

Answer 6

आप उपयोग कर सकते हैं: svn copy FROM_URL1 FROM_URL2 URL_TO

उदाहरण के लिए: कैसे एक टैग में कई फ़ाइलें, भंडार में बिखरे हुए कॉपी और इस तरह एक लेन-देन यह तेजी से बनाने के लिए:

svn copy svn://192.168.1.50/trunk/folder1 svn://192.168.1.50/trunk/folder2 svn://192.168.1.50/tags/MY_TAG 

Answer 7

मैं इसी तरह की समस्या का सामना करना पड़ रहा था एक संशोधन

svn mkdir TMP_DIR 
svn mkdir TMP_DIR\MY_TAG 
svn cp --parents src\test\File.txt TMP_DIR\MY_TAG\src\test\File.txt 
svn cp --parents src\test2\File2.txt TMP_DIR\MY_TAG\src\test2\File2.txt 
svn cp -m "comment" TMP_DIR\MY_TAG "http://myrepohost/myrepo/tags/" 
svn rm --force TMP_DIR 

आशा व्यक्त की कि मदद करता है: सबसे आसान तरीका, अस्थायी कार्य कॉपी निर्देशिका बनाने के लिए सभी की जरूरत फ़ाइलों की प्रतिलिपि और फिर दूरदराज के भंडार के लिए स्थानीय कार्य कॉपी कॉपी और अस्थायी निर्देशिका को दूर है।

Answer 8

आपका कार्यप्रवाह/कोड संगठन गलत है:

यदि आप अलग संकुल के बीच साझा किया गया गया है कोड, यह स्पष्ट रूप से एक अलग से एक में अंतर्गत आता है। प्रति पेड़ एक पेड़।

कुछ पर्यावरण में एक साथ (विशिष्ट संस्करणों के) कई संकुल डालने के ऊपर एक अलग स्तर पर संबंध रखता है (उदाहरण के लिए एक बड़ा सॉफ्टवेयर, कई संभवतः वैकल्पिक, घटकों से मिलकर उत्पाद।): Distro, और द्वारा नियंत्रित किया जाता है distro के पैकेज प्रबंधन बुनियादी ढांचे।