VPN-এর ওপর SSHFS-এ git status ধীরে চলে: কাজটি সরান

200 MB ফাইল কপি করুন, দেখবেন তা উড়ে যায়। একই ডিরেক্টরিতে git status চালান, অপেক্ষা এত দীর্ঘ হবে যে অন্য কাজে মন সরিয়ে নিতে হবে। এই দুই পর্যবেক্ষণ পরস্পরবিরোধী নয়, কারণ বাল্ক ট্রান্সফার থ্রুপুট মাপে, আর Git মাপে প্রতি সেকেন্ডে কতগুলো ছোট ফাইলসিস্টেম প্রশ্ন করা যায়, এবং মাউন্ট করা দূরবর্তী গাছ প্রতিটি প্রশ্নকে এক রাউন্ড ট্রিপে পরিণত করে। VPN টিউন করলে ভুল আকৃতির কাজের চাপ ঠিক হবে না।

কেন status ভুল মাপকাঠি

Git-কে অনেক ফাইল সম্পর্কে জানতে হয়: কোনটি পরিবর্তিত, কোনটি আনট্র্যাকড, এবং ক্যাশ করা ইনডেক্স ডেটা এখনও ডিস্কে থাকা ডেটার সঙ্গে মেলে কি না। SSHFS-এর ওপর এই প্রতিটি পর্যবেক্ষণ নেটওয়ার্ক অপারেশন হতে পারে। এখানে কাজের একক ফাইলের সংখ্যা, মেগাবাইট নয়।

তাই ক্লোনের পর প্রথম status ধীর, আর তাই বিল্ড আউটপুটে ভরা গাছে পরেরগুলো আরও ধীর হতে পারে। আনট্র্যাকড স্ক্যানিং এমন ডিরেক্টরিতে হাঁটে যা আপনার দরকার নাও হতে পারে, আর প্রতিটি পদক্ষেপ লিঙ্কের ওপর আরেকটি অনুরোধ। 40 ms-এর পথে কয়েক হাজার এন্ট্রির গাছ কয়েক হাজার রাউন্ড ট্রিপে পরিণত হয়। এই হিসাব নিশ্চিত করতে প্যাকেট ক্যাপচার লাগে না।

ডাউনলোড বেঞ্চমার্ক বলে লিঙ্ক ঠিক আছে; হাজারটি ছোট পড়া আজ বিকেলে শেষ হবে কি না তা এটি কিছুই বলে না।

কাজের গাছ সরান, টিউনিং নব নয়

লোকাল ক্লোন কাজের গাছ, ইনডেক্স ও Git অপারেশনগুলোকে একই মেশিনে রাখে। তখন pull একটি দৃশ্যমান নেটওয়ার্ক ধাপ হয়, প্রতিটি ফাইল যাচাই নয়।

এটি তখনই মানানসই যখন ডেভেলপার প্রয়োজনীয় সোর্স লোকালে রাখতে পারেন, আর বেশিরভাগ সময়ই তা সম্ভব। এটি কমিট ও ডিপ্লয়মেন্টের সীমাও আরও স্পষ্ট করে, কারণ লোকাল ফাইল সম্পাদনা আর দুর্ঘটনাক্রমে চলমান দূরবর্তী সার্ভিস বদলায় না; পরিবর্তনটি অন্যদের মতোই পুশ ও ডিপ্লয় করতে হয়। বিনিময়ে কোড দুই জায়গায় থাকে, তাই ঠিক করুন কোন কপিটি প্রামাণিক এবং সার্ভারে করা হটফিক্স কীভাবে রিপোজিটরিতে ফিরবে। সেই আলোচনা এমন একটি status কমান্ডের চেয়ে কম খরচের, যা কেউ চালাতে চায় না।

ওয়ার্কস্পেস দূরবর্তীই থাকলে সেখানেই Git চালান

কখনও ওয়ার্কস্পেস সরানো যায় না: বিল্ডের ওই পরিবেশ দরকার, ডেটা খুব বড়, বা নীতি সোর্সটি হোস্টে রাখে। তখন ফাইলের পাশেই Git ও প্রাসঙ্গিক ডেভেলপমেন্ট টুল চালান, অনুমোদিত দূরবর্তী শেল বা দূরবর্তী-ডেভেলপমেন্ট পরিবেশের মাধ্যমে। এডিটর ল্যাপটপে থাকতে পারে, তার ব্যাকএন্ড কাজের গাছের পাশে কাজ করবে।

তখন ব্যয়বহুল অপারেশনগুলো দূরবর্তী হোস্টে লোকালভাবে ঘটে, আর নেটওয়ার্ক হাজারো stat কলের বদলে এডিটরের ট্রাফিক বহন করে। এটি লোকাল ক্লোনের মতোই সমাধান, শুধু মাইগ্রেশন নয়, ডিপ্লয়মেন্টের সিদ্ধান্ত হিসেবে প্রকাশ করা।

সিঙ্ক একটি মালিকানাযুক্ত কর্মপ্রবাহ, ক্যাশ নয়

সিঙ্ক করা ওয়ার্কস্পেস পুনরাবৃত্ত দূরবর্তী পড়া কমাতে পারে, কিন্তু এটি স্বচ্ছ ক্যাশ নয়। প্রতিটি পরিবর্তনের জন্য একজন মালিক, দ্বন্দ্বের জন্য একটি নিয়ম, এবং উৎপন্ন ফাইল নিয়ে সম্মতি দরকার যা দুই পক্ষই নিজের বলে মনে করে। ওই নিয়মগুলো ছাড়া ব্যবস্থাটি সুবিধার বদলে মতবিরোধ তৈরি করে।

সেগুলো ছাড়া দ্বিমুখী সিঙ্ক করা সমস্যার সমাধান করে নতুন এক সমস্যা তৈরি করে, সাধারণত এমন একটি মার্জ যা কেউ কারও নামে বলতে পারে না। একই ভাগ করা কাজের গাছে দুটি Git প্রসেস চালানো এড়িয়ে চলুন, যদি না আপনি বুঝতে পারেন তারা কীভাবে সমন্বয় করে।

তারপর টিউন করুন, আর SSH ঠিক রাখুন

ব্যবস্থাটি ঠিক হওয়ার পর দুটি সেটিং বদলায় Git-কে কত ফাইল সম্পর্কে জিজ্ঞাসা করতে হবে: status.showUntrackedFiles এবং core.untrackedCache-এর পেছনের আনট্র্যাকড ক্যাশ। কোনোটিই 40 ms জুড়ে প্রতিটি প্রশ্নের খরচ বদলায় না; তারা শুধু প্রশ্নের সংখ্যা বদলায়। রাউন্ড ট্রিপগুলো লোকাল হওয়ার পরেই কোনো নব ঘোরান।

একটি বড় ফাইল কপি করা বেঞ্চমার্ক থেকে যুক্তি না করে যে কমান্ডটি আপনাকে বিরক্ত করে তার সময় মাপুন, আর সমর্থিত SSH এনক্রিপশনকে অক্ষত রাখুন। অচল সাইফার রাউন্ড ট্রিপ ছোট করে না; এটি দ্বিতীয় একটি সমস্যা যোগ করে যা প্রথমটির চেয়ে বেশি টিকে থাকে। git status রেফারেন্স একবার পড়ার মতো, কারণ কমান্ডটি তার নাম যা বোঝায় তার চেয়ে অনেক বেশি কাজ করে।