विलय एक्सकोड परियोजना फ़ाइलों

शाखाओं में विलय करते समय अक्सर एक्सकोड प्रोजेक्ट फ़ाइल (Project.xcodeproj/project.pbxproj) में संघर्ष होते हैं (मैं गिट का उपयोग कर रहा हूं)। कभी-कभी यह आसान होता है, लेकिन कभी-कभी मैं भ्रष्ट प्रोजेक्ट फ़ाइल के साथ समाप्त होता हूं और उसे वापस लेना पड़ता है। सबसे बुरे मामले में मुझे फाइलों में ड्रैग करके मैन्युअल रूप से प्रोजेक्ट फ़ाइल को ठीक करना होगा (जिसे पिछले के साथ स्क्वैश किया जा सकता है)विलय एक्सकोड परियोजना फ़ाइलों

क्या किसी के पास बड़ी और जटिल में मर्ज टकराव को संभालने के लिए युक्तियां हैं एक्सकोड परियोजना फ़ाइल जैसी फ़ाइलें?

EDIT-- कुछ संबंधित प्रश्न:

Git and pbxproj

Should I merge .pbxproj files with git using merge=union?

संसाधन:

http://www.alphaworks.ibm.com/tech/xmldiffmerge

http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge

http://tdm.berlios.de/3dm/doc/thesis.pdf

http://www.cs.hut.fi/~ctl/3dm/

http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/

स्रोत

2010-10-26 Felixyz

दिलचस्प सवाल। दुर्भाग्य से मुझे लगता है कि कोई समाधान नहीं है - मुझे उत्सुकता है कि कोई अच्छा जवाब देगा या नहीं। यदि नहीं, तो http://stackoverflow.com/questions/3929087/dividing-a-project-into-multiple-xcode-project-files/3932613#3932613 पर एक नज़र डालें :) –

1) अपनी परियोजनाओं छोटे, अधिक तार्किक पुस्तकालयों/संकुल में टूट। बड़े पैमाने पर परियोजनाएं नियमित रूप से खराब डिजाइन का संकेत होती हैं, जैसे वस्तु बहुत अधिक होती है या रास्ता बहुत बड़ा होता है।

2) आसान पुनर्निर्माण के लिए डिज़ाइन - यह उन कार्यक्रमों को लिखने में भी मदद करता है जिन्हें एकाधिक टूल या आईडीई द्वारा बनाया जाना चाहिए। मेरी कई परियोजनाओं को एक निर्देशिका जोड़कर पुनर्निर्मित किया जा सकता है।

3) बाहरी निर्माण चरणों को हटा दें। उदाहरण: मैंने सभी परियोजनाओं से "कॉपी हेडर" बिल्ड चरण हटा दिया है। स्पष्ट रूप से निर्देश शामिल करने के माध्यम से विशिष्ट फ़ाइलों को शामिल करें।

4) जहां भी संभव हो xcconfig फ़ाइलों का उपयोग करें। यह आपके निर्माण को अपडेट करते समय आपको आवश्यक परिवर्तनों की संख्या भी कम कर देता है। xcconfig फ़ाइलें बिल्ड सेटिंग्स का संग्रह परिभाषित करती हैं, और #include का समर्थन करती हैं। बेशक, जब आप xcconfig का उपयोग करने के लिए परिभाषित करते हैं तो आप प्रत्येक प्रोजेक्ट से लक्षित (बहुमत) उपयोगकर्ता परिभाषित सेटिंग्स को हटाते हैं।

5) लक्ष्य निर्भरताओं के लिए: लक्ष्य बनाएं जो भौतिक परिचालनों के बजाय तार्किक परिचालन करते हैं। यह आमतौर पर एक शेल स्क्रिप्ट लक्ष्य या कुल लक्ष्य होता है। उदाहरण के लिए: "निर्भरताएं बनाएं", "सभी यूनिट परीक्षण चलाएं", "सभी बनाएं", "सभी साफ़ करें"। तो आपको प्रत्येक निर्भरता को हर तरह के कदम को बदलने की ज़रूरत नहीं है - यह संदर्भों का उपयोग करने जैसा है।

6) अपने कोड के लिए एक आम "स्रोत वृक्ष" परिभाषित करें, और तीसरे पक्ष के स्रोतों के लिए दूसरा।

7) बाहरी निर्माण उपकरण उपलब्ध हैं। यह आपके लिए एक विकल्प हो सकता है (कम से कम, अपने कुछ लक्ष्यों के लिए)।

इस बिंदु पर, एक xcodeproj बहुत आसान होगा। इसके लिए कम परिवर्तन की आवश्यकता होगी, और पुनर्निर्माण के लिए बहुत आसान हो जाएगा। आप अपनी परियोजनाओं की जटिलता को कम करने और निर्माण करने के लिए इन अवधारणाओं के साथ और आगे जा सकते हैं।

स्रोत

2010-11-01 07:21:10 justin

महान सुझाव, हालांकि वे हल करने के बजाए घुसपैठ करते हैं समस्या। 1 + 6 मैं पहले से ही कर रहा हूँ। 4 + 5 मैं विचार करूंगा। 2 + 7 - क्या आप अधिक जानकारी प्रदान कर सकते हैं? – Felixyz

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

(cont) निर्भरताओं, (निर्देशिका) की एक निर्देशिका के आधार पर किसी भी लक्ष्य को पुनर्निर्माण करने की क्षमता हो, और एक एक xcconfig के अलावा। यदि कोई प्रोजेक्ट दूषित हो गया है या किसी अन्य विचार (या xcode का संस्करण) में उपयोग किया जाना चाहिए, तो आयात 1 मिनट से भी कम समय लेता है। यह मुख्य परियोजना पेड़ से अप्रयुक्त बिट्स को रखने में भी मदद कर सकता है। यह संयुक्त निर्माण करने में भी आसान बनाता है। यदि आप घोषणापत्र शुद्धता wrt के बारे में जुनूनी हैं जो निर्यात और दृश्यता (जो कि यदि आप गैर-तुच्छ कार्यक्रमों पर काम कर रहे हैं तो निश्चित रूप से चिंता होनी चाहिए), तो आप एक बहुत ही कम समय में संयुक्त निर्माण कर सकते हैं। (cont) – justin

मुझे मिला सबसे अच्छा तरीका यह है कि गिट को .pbxproj फ़ाइल को द्विआधारी के रूप में इलाज करने का निर्देश देना है। यह गन्दा विलय को रोकता है।

अपने .gitatributes फाइल करने के लिए इस जोड़ें:

*.pbxproj -crlf -diff -merge

स्रोत

2010-12-06 22:58:16 radven

भौतिक विलय में इससे क्या अंतर होता है? – esbenr

यदि यह फ़ाइल प्रभावी रूप से द्विआधारी बनाता है, तो यह विलय को कैसे आसान बनाता है? – damian

कृपया इन्हें जांचें: http://robots.thoughtbot.com/xcode-and-git-bridging-the-gap ---- उद्धरण: इस प्रकार की फ़ाइल में उपयोग किए गए कस्टम प्रारूप की वजह से, यह है वही हम क्या चाहते हैं। जब इस फ़ाइल के लिए विलय विवाद उत्पन्न होता है, तो गिट स्वचालित रूप से संघर्ष के दोनों किनारों के परिवर्तनों को जोड़ देगा, पहले अपस्ट्रीम परिवर्तनों को लागू करेगा। – chakming

दो Xcode परियोजनाओं की तुलना खुला खुला FileMerge करने के लिए (मनु फलक से खुला xcode और चुनें Xcode() -> ओपन डेवलपर उपकरण -> FileMerge) । अब "बाएं" बटन पर क्लिक करें और एक्सकोड परियोजना मुख्य निर्देशिका खोलें। तुलना करने के लिए "दाएं" बटन पर क्लिक करें और xcode प्रोजेक्ट मुख्य निर्देशिका खोलें।

अब "विलय करें" बटन पर क्लिक करें!

यह बात है!

स्रोत

2013-01-06 07:54:57 evya

सबसे आसान, यदि आप गिट का उपयोग कर रहे हैं: 'git config --global merge.tool opendiff' (केवल एक बार किया जाना आवश्यक है), तो' git mergetool' इसे आपके लिए लॉन्च करेगा। – damian

मुझे अस्पष्ट है कि फाइलमेज विशेष रूप से एक्सकोड परियोजना फ़ाइलों के लिए विशेष समर्थन है? – Benjohn

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

स्रोत

2013-03-05 15:22:42

आप https://github.com/simonwagner/mergepbx/

कोशिश करने के लिए यह एक स्क्रिप्ट आप XCode प्रोजेक्ट सही ढंग से फ़ाइलें विलय करने के लिए मदद मिलेगी है चाहते हो सकता है। ध्यान दें कि यह अभी भी अल्फा है।

अस्वीकरण: मैं mergepbx का लेखक हूं।

स्रोत

2014-02-04 12:38:12 Simon

साइमन, क्या इस परियोजना को इस समय परिपक्व है? –

अच्छा, यह मेरे लिए काम करता है - तो हाँ? दुर्भाग्य से यह सुनिश्चित करने की कोई संभावना नहीं है कि यह वास्तव में वहां सबकुछ के साथ काम कर सके, क्योंकि प्रोजेक्ट फ़ाइल प्रारूप के बारे में कोई दस्तावेज नहीं है। तो यह "मेरे लिए काम करता है और अब तक किसी ने शिकायत नहीं की है" से बेहतर कभी नहीं होगा। – Simon

साइमन - विकास और क्यूए में वर्षों खर्च करने के बाद, "अच्छा, यह मेरे लिए काम करता है" सुन रहा है, जो मुझे डराता है। शायद यह सब मिला है, लेकिन अभी भी। –

विलय एक्सकोड परियोजना फ़ाइलों

उत्तर

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