একটি মডুলার সিস্টেমে সংস্করণ নিয়ন্ত্রণ ব্যবহার করার কৌশল

Question

ধরা যাক (সরলতার জন্য) আমাদের কাছে ক্লায়েন্ট এবং সার্ভারের বৈশিষ্ট্যযুক্ত একটি অ্যাপ্লিকেশন রয়েছে; উভয়ের জন্য আলাদা আলাদা সংগ্রহস্থল ব্যবহার করার জন্য কি আরও ভাল ধারণা আছে?

এগুলিকে মিশ্রিত করা সম্ভবত পারস্পরিক সম্পর্কের পরিবর্তনগুলি ট্র্যাক করার এবং পারস্পরিক সম্পর্কযুক্ত শাখাগুলি (যেমন প্রোটোকল বিবর্তন) বজায় রাখা সহজতর করবে, তবে অন্যদিকে স্বতন্ত্র বিকাশকে আরও বিশৃঙ্খল করে তুলবে ...

Comments

এবং পৃথক শাখা ব্যবহারে কি সমস্যা? একজন বিকাশকারীকে কেবল বর্তমানে স্থানীয়ভাবে খোলা জায়গায় কাজ করা শাখা থাকা দরকার, তাই তিনি এমনকি অন্য শাখাগুলিতে থাকা স্টাফটি এমনকি দেখতে পাবেন না। তবে, যদি কোনও কারণে তাকে শাখায় toোকার প্রয়োজন হয়, তবে তিনি পারেন।

— স্পেনসার রথবুন

@ স্পেন্সাররাথবুন - এর মতো পৃথক শাখা ব্যবহার করা বিপর্যয়ের প্রতিকার । সার্ভার এবং ক্লায়েন্ট, বিশেষত ইন্টারফেস এবং সিস্টেম ডকুমেন্টেশন ইত্যাদির মধ্যে ফাইলগুলি ভাগ করা সত্যিই কঠিন হবে একটি ডিভিসিএসের সাহায্যে আপনার ক্লায়েন্ট এবং সার্ভারের সমস্ত কমোন ক্লোন করা প্রয়োজন, এমনকি যদি আপনি কেবল একটি চান, এবং আপনাকে না দেন কোন ক্লায়েন্ট এবং সার্ভার সংস্করণগুলি একসাথে কাজ করবে সে সম্পর্কে কোনও ইঙ্গিত। মনোলিথিক (একক) সংগ্রহস্থল বা একটি মডুলার (একাধিক) ভাণ্ডার ভাঙ্গনের তুলনায় আপনি উভয় পৃথিবীর মধ্যে সবচেয়ে খারাপ পান ।

— মার্ক বুথ

@ মারকবুথ হুম, আমি প্রতিটি শাখায় প্রকল্প বিভাগগুলির কথা ভাবছিলাম, যেহেতু তিনি ইঙ্গিত করেছেন যে তারা কোড ভাগ করে নেবে। প্রতিটি বিভাগকে যথাযথ শাখা হিসাবে ট্যাগ করুন এবং আপনি ভাল। আপনার ডিভিসিএস কি কোনও ফাইল / প্রতিশ্রুতিবদ্ধকে একাধিক ট্যাগ রাখার অনুমতি দেয় না?

— স্পেনসার রথবুন

Answer 1

আপনি ব্যবহার করে থাকেন Git বা তত্পর , তাহলে আপনি তাকান করতে চাইবেন submodules বা subrepositories ।

ক্লায়েন্ট, সার্ভার এবং তাদের ইন্টারফেস ফাইলগুলি তাদের নিজস্ব সংগ্রহস্থলে থাকবে তবে সুপার-সংগ্রহস্থল স্তরে একসাথে আবদ্ধ হবে । এটি আপনাকে শীর্ষ স্তরে একটি চেকআউট করার অনুমতি দেয় এবং gitবা hgসাবমডিউলগুলি / সাবরেপোসিটরিগুলির প্রত্যেকটির উপযুক্ত প্রতিশ্রুতি পরীক্ষা করতে পারে।

ক্লায়েন্ট এবং সার্ভার উভয়ই একে অপরের পক্ষে উপযুক্ত হলে কেবলমাত্র সুপার-রিপোজিটরির প্রতিশ্রুতিবদ্ধ করে, সুপার-রেপোজিটরি আপনাকে কেবল একটি ওয়ার্কিং সিস্টেম পরীক্ষা করার বিকল্প দেয় - সুতরাং আপনি কখনই কোনও নতুন ক্লায়েন্টকে কোনও পুরানো বিরুদ্ধে চালানোর চেষ্টা করবেন না সার্ভার বা তদ্বিপরীত।

সাবমডিউলস / সাবরেপোজিটরিগুলি আপনাকে একক একক একক সংগ্রহস্থলের সুবিধার পাশাপাশি পৃথক সংগ্রহশালা ব্যবহারের সমস্ত সুবিধা দেয়, কিছুটা অতিরিক্ত জটিলতার ব্যয় করে।

_{এই উত্তরটি অন্য এসসিএমগুলির পক্ষে gitবা hgঅন্যদের পক্ষে উকিল করার উদ্দেশ্যে নয় , কেবল এটি ঘটে যায় যে আমি কেবল এই এসসিএমগুলিকেই যথেষ্ট জানি যে এই বিকল্পটি বিদ্যমান রয়েছে তা জানতে। আমি বুঝতে পারি না svnবাহ্যিকভাবে উদাহরণস্বরূপ কীভাবে কাজ করে।}

Comments

এখন এটি একটি আকর্ষণীয় বৈশিষ্ট্য। আমি এর ব্যবহার সম্পর্কে কিছু সঠিক কেস স্টাডি দেখতে আগ্রহী হব, আমি এটির আগে শুনিনি!

— এড জেমস

সাবভার্সনের ক্ষেত্রে অনুরূপ জিনিস হ'ল বাহ্যিক সংজ্ঞা: svnbook.red-bean.com/en/1.0/ch07s03.html । তবে এটি কিছুটা ভিন্ন উপায়ে কাজ করে।

— লিওরি

@ মারকবুথ: হ্যাঁ, আপনি পারেন। সেই পৃষ্ঠায় আপনি -R12345 এর মতো দেখতে পরামিতিগুলি দেখতে পারেন - যারা সংশোধন করতে চান তা নির্ধারণ করে। এবং যেহেতু এসএনএন: বহিরাগত সম্পত্তি যে কোনও পাঠ্য ফাইলের মতো সংস্করণযুক্ত, আপনার প্রতিটি সংশোধনের জন্য -r এর জন্য আলাদা আলাদা মান থাকতে পারে। এছাড়াও, আপনি প্রাচীন 1.0 ডকুমেন্টেশন ব্রাউজ করছেন। বাহ্যিক সংজ্ঞাগুলি 1.5 তে পরিবর্তন করা হয়েছিল এবং বর্তমান সংস্করণটি 1.7। দেখুন: svnbook.red-bean.com/en/1.7/svn.advanced.externals.html

— লাইওরি

Answer 2

আলাদা করুন!

আসলে, আমার সম্ভবত তিনটি সংগ্রহস্থল থাকবে, একটি ক্লায়েন্ট এবং কেবলমাত্র ক্লায়েন্ট-কেবল গ্রন্থাগারের জন্য, একটি সার্ভারের জন্য (এবং সম্পর্কিত লাইব্রেরি), এবং একটি ভাগ করা লাইব্রেরির জন্য (এপিআই ইন্টারফেসগুলি অন্তর্ভুক্ত করে যা দুটির মধ্যে কার্যকারিতা প্রকাশ করে) , এবং অন্য কোনও ভাগ করা কোড)। আমি মনে করি এটি সত্যই কী, ভাগ করা কোডটি তার নিজস্ব একটি পৃথক ভান্ডারে যেতে হবে। এইভাবে আপনি নিশ্চিত করতে পারেন যে আপনার ক্লায়েন্ট এবং সার্ভারের মধ্যে আন্তঃক্ষমতা সবসময় একই সংস্করণে রয়েছে এবং এর প্রতিটি গ্রাহকের ডিজাইন থেকে বিচ্ছিন্ন is

স্পষ্টতই, আপনি যে নির্দিষ্ট যোগাযোগ কাঠামোটি ব্যবহার করছেন তার উপর নির্ভর করে এটি সর্বদা সম্ভব নয়, তবে সম্ভবত এমন একটি ভাগ করা কোড রয়েছে যা ডেটা-ট্রান্সফার অবজেক্টগুলির বিন্যাস বা আপনার কাস্টম প্রোটোকলের (বা অন্য কোনও উদাহরণ) হ্যান্ডশেক স্টেপস নির্ধারণ করে ates ।

ধরে নিচ্ছি আপনার কাছে মোটামুটি শালীন কন্টিনিউজ ইন্টিগ্রেশন এবং কিউএ সেটআপ রয়েছে (আমার অভিজ্ঞতা অনুসারে একটি মোটামুটি বড় অনুমান, তবে একটি আমি তবুও করতে যাচ্ছি। আপনার যদি কিউএ বিভাগ না থাকে তবে আপনার কমপক্ষে কিছুটা সিআই করা উচিত) আপনার উচিত হবে সম্ভাব্য কোড মিস-মিলগুলির বিরুদ্ধে প্রতিরক্ষা হিসাবে একক-রেপো প্যাটার্নটি ব্যবহার করার দরকার নেই, হয় আপনার সিআই সার্ভারটি গ্রন্থাগার-আন্তঃক্রিয়াশীলতা ফ্ল্যাগ করবে বা আপনার কিউএ টিম রানটাইম ত্রুটিগুলি ধরবে (বা আরও ভাল, আপনার ইউনিট টেস্টগুলি করবে)।

বিভক্ত সংগ্রহস্থলের সুবিধাগুলি কোনও সিস্টেমের পৃথক পৃথক অংশ সংস্করণ করার ক্ষমতাতে অন্তর্ভুক্ত। কোনও পারফরম্যান্স ইস্যুটির মূলটি চেষ্টা করতে এবং লক করার জন্য, গত সপ্তাহের সার্ভারের একটি অনুলিপি নিতে এবং এই সপ্তাহের ক্লায়েন্টের সাথে এটি চালাতে চান? কোন চিন্তা করো না.

Answer 3

ইন Mercurial , এই প্রকল্প ব্যবহার করা যেতে পারে ব্যবহার ->বোঝাতে subrepo সম্পর্ক:

product -> client -|-> (many components)
                   |->  shared component A

        -> server -|-> (many components)
                   |->  shared component A

পণ্যের সাবরেপোস ক্লায়েন্ট, সার্ভার রয়েছে। এগুলির প্রত্যেকেরই সাব্রেপোস হিসাবে তাদের উপাদান রয়েছে, সম্ভবত দুজনের মধ্যে ভাগ করে নেওয়া কমপক্ষে একটি সাবরেপো।

ট্যাগিং সম্ভবত প্রথম দুটি স্তরে করা উচিত, তার নীচে নয়।

কমিটগুলি উপাদান স্তরের উপর সম্পন্ন করা হয়, সুপাররেপস কার্যকরভাবে নামের শাখা এবং পণ্যের সংস্করণগুলি ট্র্যাক করে। নামযুক্ত শাখা / বুকমার্কগুলি ব্যবহারযোগ্যতার জন্য ক্লোন শাখার চেয়ে ভাল (যেমন ট্রেনিবিলিটি) এবং সাবরেপসের সাথে সামঞ্জস্যযোগ্য।

HG ধৃষ্টতা প্রতি tends যে superrepos হয় পণ্য, এবং করে শীর্ষ স্তরে সম্পন্ন করা হয়, কিন্তু যে বিশেষ করে ভাল কাজ করে না যখন একাধিক পণ্য একই উপাদান ব্যবহার করুন। :-)

আমি মনে করি না যে এই স্কিমটি গিটে স্থানান্তরিত হলে খুব বেশি পরিবর্তন হবে, তবে আমি এখনও গিটে এটি চেষ্টা করে দেখিনি।

Answer 4

এটি একটি কনফিগারেশন পরিচালনার সমস্যা, পুনর্বিবেচনা নিয়ন্ত্রণ সমস্যা নয়। সর্বদা হিসাবে, একটি প্রোগ্রামার একটি পেরেক হাতুড়ি করতে একটি স্ক্রু ড্রাইভার ব্যবহার করে। আপনি কীভাবে আপনার কনফিগারেশন পরিচালনা করবেন তা পুনর্বিবেচনা নিয়ন্ত্রণটি নিজেই যত্ন নেবে Work

Answer 5

সবচেয়ে সহজ পদ্ধিতি হল একটি একক সংগ্রহস্থল ব্যবহার করা, সুতরাং যদি না আপনি জটিলতার পক্ষে জটিলতা পছন্দ করেন, তবে অন্যথায় বাধ্যতামূলক যুক্তিগুলির অভাবে এটি ডিফল্ট পছন্দ হওয়া উচিত।

ক্লায়েন্ট এবং সার্ভার বিকাশ কি বিভিন্ন সংস্থা দ্বারা সম্পাদিত হতে চলেছে? ক্লায়েন্ট (বা সার্ভার) এর একাধিক বাস্তবায়ন হবে? ক্লায়েন্ট ওপেন সোর্স এবং সার্ভার বাস্তবায়ন গোপন? যদি এই সমস্ত প্রশ্নের উত্তর "না" হয় তবে একক সংগ্রহস্থল ছাড়া আরও জটিল কিছু হ'ল কেবল কোনও উপকারের জন্য অসুবিধা আনতে পারে।

যদি আপনি পৃথক কোডবেস বজায় রাখা বেছে নেন, আপনার কীভাবে এটি পরিচালিত হবে সে সম্পর্কে পরিষ্কার নীতিমালা প্রয়োজন, যাতে অসম্পূর্ণতা এবং নির্ভরতা নরক এড়ানো যায়। প্রথম কয়েকটি হিক্কার মাধ্যমে কাজ করার পরে, আপনি আবিষ্কার করতে পারেন যে সবচেয়ে নিরাপদ জিনিস হ'ল উভয় সংগ্রহস্থলকে একসাথে চেক করা, একসাথে তৈরি করা এবং তাদের একসাথে স্থাপন করা ... যা স্পষ্টতই এগুলি পৃথক করার পুরো উদ্দেশ্যকে পরাভূত করে!

মডুলারালিটি হ'ল একটি দুর্দান্ত সম্পত্তি, তবে ভাণ্ডার ভাণ্ডারগুলি অর্জন করার কোনও সরঞ্জাম নয়। পূর্ববর্তী অনুচ্ছেদে বোঝা যাচ্ছে, আপনার অত্যন্ত সংযুক্ত উপাদান থাকতে পারে যা একাধিক কোডবাসের (অযাচিত) বিভক্ত হয়ে থাকে এবং একইভাবে একই কোডবেজে (আকাঙ্ক্ষিত) মধ্যে আপনার অত্যন্ত মডুলার উপাদান থাকতে পারে।

একাধিক উপলক্ষে, আমি আমার দলকে বিদ্যমান গিট সংগ্রহস্থলগুলিকে একীভূত করার জন্য (সফলভাবে) পরামর্শ দিয়েছি, কারণ এটি উন্নয়ন এবং স্থাপনাকে সহজতর করেছে।

Answer 6

এক মুহুর্তের জন্য ভান্ডারটি ভুলে যান। আপনি কারও সাথে ভাগ না নিলে আপনি কীভাবে দুটি মেশিনে এই প্রকল্পগুলি সংগঠিত করবেন? দলের বাকি সদস্যরা কীভাবে এটি করবে? আপনি কি...

• ক্লায়েন্ট এবং সার্ভার উভয়ের জন্য সমস্ত উত্স ফাইল একই ডিরেক্টরিতে রাখবেন?

• একটি মূল প্রকল্প ডিরেক্টরি তৈরি করুন যা ক্লায়েন্ট এবং সার্ভারের উপ-ডিরেক্টরি অন্তর্ভুক্ত করবে?

• দুটি প্রকল্প সম্পূর্ণ আলাদা রাখবেন?

আপনি যখন দল হিসাবে এই বিষয়ে কিছুটা sensক্যমত্যে পৌঁছে যান, আপনি আপনার কোড সংগ্রহস্থলগুলিতে প্রকল্পগুলি পরীক্ষা করতে প্রস্তুত। আমি যে সমস্ত রিভিশন কন্ট্রোল সরঞ্জামগুলির কথা ভাবতে পারি সেগুলি আপনার পছন্দসই ডিরেক্টরি কাঠামোর পুনরুত্পাদন করতে খুশি - কোন ফাইলটি কোন প্রকল্পের অন্তর্ভুক্ত তা তারা কিছুটা বিবেচনা করে না। এবং একটি ভান্ডার বা দুটি (বা ছয়) থাকার মধ্যে পার্থক্যটি সাধারণত সামান্য প্রশাসনিক পার্থক্য বাদ দিয়ে এত বড় হয় না।

উদাহরণস্বরূপ, সাবভার্সনের সাথে, ক্লায়েন্ট এবং সার্ভারের জন্য পৃথক সংগ্রহস্থল এবং একক সম্মিলিত সংগ্রহস্থলের মধ্যে বৃহত্তম পার্থক্যটি পুনর্বিবেচনার সংখ্যাগুলি পরিবর্তনের পথে। একটি সেজ রেপোজিটরির সাহায্যে, ক্লায়েন্ট বা সার্ভারের যে কোনও একটিতে আপনি কোড দেওয়ার সময় সংস্করণ নম্বর বাড়বে। পৃথক সংগ্রহস্থল সহ, সার্ভার প্রকল্পের প্রতিশ্রুতি ক্লায়েন্টের জন্য প্রধান সংশোধন নম্বর পরিবর্তন করবে না।