नेटवर्कमा परियोजना साझा गर्दा Xcode सर्दैन, किनभने एप तपाईंको Mac मा चलिरहन्छ र सर्भरसँग परियोजनाको डेटा मागिरहन्छ। टाढाको Mac मा Xcode चलाएर त्यसको स्क्रिन हेर्नु अर्को व्यवस्था हो, जहाँ एप र यसका फाइलहरू सँगै रहन्छन् र लिङ्कले देखावट र तपाईंको इनपुट मात्र बोक्छ। केही पनि कन्फिगर गर्नुअघि यीमध्ये कुन चाहनुहुन्छ भनेर ठेगान गर्दा पछिको अधिकांश अलमल हट्छ।

सामान्य अवस्थाहरूलाई तीन व्यवस्थाले समेट्छन्, र ती कार्यक्षेत्र कहाँ रहन्छ र कुन मेसिन कम्पाइल गर्छ भन्नेमा फरक पर्छन्। अगाडि बढ्नुअघि दुवै बुँदाको उत्तर लेख्नुहोस्।

Xcode चलाउने मेसिनको नाम भन्नुहोस्

पहिलो व्यवस्थामा सबै स्थानीय छ: कामको प्रतिलिपि, इन्डेक्स र बिल्ड सबै तपाईंको Mac मा रहन्छन्, र नेटवर्कले रिपोजिटरी र निर्भरताको ट्राफिक मात्र बोक्छ। दोस्रोमा परियोजना Xcode सँगै टाढाको Mac मा रहन्छ, त्यसैले इन्डेक्सिङ र कम्पाइलेसन फाइलहरूको छेउमा हुन्छ, लिङ्कले स्क्रिनको सामग्री र कुञ्जी थिचाइ बोक्छ। तेस्रोमा सम्पादन स्थानीय रूपमा हुन्छ र स्पष्ट स्रोत हस्तान्तरणपछि टाढाको होस्टमा बिल्ड चल्छ। कुनले के सार्छ भन्ने तालिकाले बताउँछ।

ArrangementWhere the source livesWhat crosses the link
Everything localLocal diskRepository and dependency traffic
Remote Xcode, screen sharedRemote diskDisplay frames and input events
Local edit, remote buildBoth, with a handoffSource transfer, then build output

पहिले बीचको स्तम्भ पढ्नुहोस्, किनभने असफलता कहाँ देखिन्छ भन्ने त्यसले निर्धारण गर्छ। स्रोत टाढा भएको कार्यप्रवाह लिङ्क ढिलो हुँदा असफल हुन्छ, जबकि टाढाको कम्पाइलर भएको कार्यप्रवाह हस्तान्तरण अस्पष्ट हुँदा असफल हुन्छ। तेस्रोले मात्र तपाईंलाई दुवैको जिम्मेवार बनाउँछ।

मेगाबाइट होइन, आवतजावत गन्नुहोस्

सम्पादक र इन्डेक्सरले धेरै साना फाइल कार्यहरू पठाउँछन्, र फाइल प्रणाली टाढा हुँदा हरेक आवतजावत बन्छ। यसले माउन्ट गरिएको कार्यक्षेत्रलाई ठूलो प्रतिलिपि नहुने तरिकाले ढिलाइप्रति संवेदनशील बनाउँछ, त्यसैले फाइल स्थानान्तरणको समय नाप्दा कार्यप्रवाह कस्तो लाग्छ भन्ने लगभग केही थाहा हुँदैन। टाढाको देखावटको उल्टो प्रोफाइल छ: त्यसले निरन्तर प्रवाह सार्छ र ढिलाइभन्दा थ्रुपुट राम्रो सहन्छ। दुवैलाई एउटा संख्याले तुलना गर्दा आत्मविश्वासी गलत उत्तर आउँछ।

कुनै पनि व्यवस्था स्वभावले सबैभन्दा छिटो होइन। सही छनोट तपाईंले वास्तवमै गर्ने काममा निर्भर छ, त्यसैले अर्को पाइला बेन्चमार्क होइन, त्यही काम प्रयास गर्नु हो।

स्रोत हस्तान्तरण स्पष्ट बनाउनुहोस्

जब दुवै मेसिनसँग कामको प्रतिलिपि हुन्छ, कुन अधिकारिक हो र टाढाको बिल्डले कुन संस्करण प्रयोग गर्यो ठेगान गर्नुहोस्। एउटै माउन्ट गरिएको कार्य वृक्षलाई दुई उपकरणले सम्पादन गर्नुभन्दा कमिट स्पष्ट हस्तान्तरण हो, किनभने कमिटसँग पहिचान हुन्छ र माउन्टसँग हुँदैन। उत्पन्न आउटपुट र इन्डेक्स डेटालाई पनि मालिक चाहिन्छ, किनभने ती स्रोतबाट पुनर्निर्माण हुन्छन् र स्रोतजस्तै यात्रा गर्नुहुँदैन। द्वन्द्व नियमबिनाको दुईतर्फी ऐना कार्यप्रवाह होइन, त्यो दौड हो।

टाढाबाट बिल्ड गर्न यो पनि चाहिन्छ टाढाको होस्टसँग सही उपकरण श्रृंखला हुनु र निजी निर्भरताका लागि प्रमाणहरू। होस्टसम्म पुग्न दिने VPN ले तपाईंको खाताको पहुँच त्यसलाई ऋण दिँदैन, र त्यहाँ Xcode स्थापना गर्दैन।

कार्यप्रवाहमा प्रतिबद्ध हुनुअघि बाटो जाँच्नुहोस्

टाढाको होस्टको वरिपरि डिजाइन गर्नुअघि त्यसलाई प्रमाणित गर्नुहोस्, त्यसपछि कार्यप्रवाहले वास्तवमै गर्ने कार्यहरूले लिङ्क मापन गर्नुहोस्। तलका आदेशहरूले उपकरण श्रृंखला, सक्रिय विकासकर्ता निर्देशिका र टाढाका कार्यक्षेत्रलाई पीडादायक बनाउने फाइल अवलोकन खर्च जाँच्छन्। अन्तिमलाई स्थानीय होइन, नेटवर्क मार्गबाट चलाउनुहोस्।

xcode-select -p
xcodebuild -version
ssh mac-builder 'xcodebuild -version'
time git status --porcelain

पूर्ण Xcode स्थापना नभएको होस्टले xcodebuild बाट त्रुटि फर्काउँछ, र यो नेटवर्क होइन, उपकरण श्रृंखलाको समस्या हो। विकासकर्ता निर्देशिकाले बिल्डले कुन Xcode प्रयोग गर्ने देखाउँछ, र केवल आदेश-लाइन उपकरणतर्फ देखाउने मार्गको अर्थ एप स्थापना नभएको हो। माउन्ट गरिएको साझेदारीमा रिपोजिटरी स्थिति आदेशको समय नाप्दा आवतजावतको खर्च सिधै खुल्छ, र स्थानीय चलनसँग तुलना गर्दा महत्त्वपूर्ण संख्या मिल्छ। त्यो अन्तर पहिले नै अप्रिय भए, वास्तविक सम्पादकमुनि माउन्ट-कार्यक्षेत्रको कार्यप्रवाह अझ नराम्रो हुनेछ।

तपाईंले कुन व्यवस्था छान्नुभयो, कुन मेसिन स्रोतको मालिक हो र हस्तान्तरण कसरी चल्छ लेख्नुहोस्। त्यो टिप्पणीले अर्को अनबोर्डिङ वा ल्यापटप परिवर्तनलाई अनुसन्धानको सट्टा कन्फिगरेसन काम बनाउँछ।

सम्बन्धित लेखहरू