नेटवर्कवर प्रकल्प सामायिक केल्याने 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 वापरेल ते दाखवते, आणि फक्त कमांड-लाइन साधनांकडे निर्देश करणारा मार्ग म्हणजे अॅप स्थापित नाही। माउंट केलेल्या शेअरवर रेपॉझिटरी स्थिती आदेशाची वेळ मोजल्यास फेरीचा खर्च थेट उघड होतो, आणि स्थानिक चालनाशी तुलना केल्यास महत्त्वाची संख्या मिळते। ती तफावत आधीच अप्रिय असल्यास, खऱ्या संपादकाखाली माउंट-वर्कस्पेस कार्यप्रवाह अधिक वाईट होईल।

तुम्ही कोणती व्यवस्था निवडली, कोणते यंत्र स्रोताचे मालक आहे आणि हस्तांतरण कसे चालते ते नोंदवा। ती नोंद पुढील ऑनबोर्डिंग किंवा लॅपटॉप बदलीला तपासणीऐवजी कॉन्फिगरेशन काम बनवते।

संबंधित लेख