আমার প্রকল্প ফাইলগুলি কি সংস্করণ নিয়ন্ত্রণে রাখা উচিত? [বন্ধ]


87

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


আরও দেখুন stackoverflow.com/questions/1429125/...
VonC

12
খুব গঠনমূলক
কিএইড

উত্তর:


93

আপনি যে কোনও পোর্টেবল সেটিং ফাইলগুলি সংস্করণে নিয়ন্ত্রণে রাখতে চান ,
অর্থ: যে
কোনও ফাইল যার কোনও নিখুঁত পথ নেই।
এটি অন্তর্ভুক্ত:

  • .প্রজেক্ট,
  • .classpath ( যদি কোনও নিখুঁত পাথ ব্যবহার না করা হয় যা আইডিই ভেরিয়েবল বা ব্যবহারকারীর পরিবেশের ভেরিয়েবলের সাহায্যে সম্ভব)
  • আইডিই সেটিংস (এটি যেখানে আমি 'গৃহীত' উত্তরের সাথে দৃ strongly়ভাবে একমত নই)। এই সেটিংগুলিতে প্রায়শই স্থির কোড বিশ্লেষণের নিয়ম অন্তর্ভুক্ত থাকে যা এই প্রকল্পটি তার কর্মক্ষেত্রের মধ্যে লোড করা কোনও ব্যবহারকারীর জন্য ধারাবাহিকভাবে প্রয়োগ করা অত্যন্ত জরুরী।
  • আইডিই নির্দিষ্ট সেটিংস পুনঃনির্দেশগুলি অবশ্যই একটি বড় README ফাইলে লিখতে হবে (এবং অবশ্যই সংস্করণযুক্ত)।

আমার জন্য থাম্বের বিধি:
আপনাকে অবশ্যই একটি প্রকল্পটিকে একটি ওয়ার্কস্পেসে লোড করতে সক্ষম করতে হবে এবং এটি যথাযথভাবে আপনার আইডিইতে সেট আপ করতে এবং কিছুক্ষণের মধ্যে যেতে হবে আপনার যা কিছু আছে তা এতে থাকতে হবে।
কোনও অতিরিক্ত ডকুমেন্টেশন, উইকি পৃষ্ঠাগুলি পড়তে হবে বা কী না।
এটি লোড করুন, সেট আপ করুন, যান।


@ ধনী: আপনাকে ধন্যবাদ : অন্যান্য পাঠকদের জন্য, রিচ এর উত্তর একই প্রশ্নের এক বছর পরে দেখা হবে stackoverflow.com/questions/1429125/...
VonC

4
মূল পর্ব "... কয়েক মিনিটের
মধ্যেই যান

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

4
@ আরএইচ - "... তাদের নিজস্ব আইডিই স্থাপনের জন্য দায়বদ্ধ হওয়া উচিত"। এটি ঠিক আছে, যতক্ষণ না কিছু ক্লাউন তাদের Eclipse কোড শৈলীর বৈশিষ্ট্যগুলি সেট করতে ভুলে যায় .... এবং তাদের মধ্যে ট্যাবগুলির সাথে উত্স ফাইলগুলিতে চেক করে। গ্রারর !!
স্টিফেন সি

4
আমি এর সাথেও একমত নই - আপনি যদি সিআই, একাধিক সংস্করণ, প্ল্যাটফর্ম, আইডিই ইত্যাদি ব্যবহার করেন তবে এটি DRY কে খুব খারাপভাবে ভেঙে দেয়। এসপি যেহেতু এখানে শেষ হয় তার উপর বিভিন্ন প্লাগইন / সেটিংসের একটি বড় প্রভাব রয়েছে।
জয়শাও

30

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


4
-1 আমি সেই প্লাগইনগুলির জন্য কয়েক হাজার মানুষের সময় নষ্ট করার পরিবর্তে বাগ রিপোর্ট ফাইল করার পরামর্শ দেব। এবং তারপরে, আমি সমস্ত স্থিতিশীল সেটিংস ফাইলগুলি সংস্করণ নিয়ন্ত্রণের আওতায় রেখেছি এবং সেই উইকি পৃষ্ঠাটি খালি হাড়ের মধ্যে ছাঁটাই করব।
অ্যারন ডিগুল্লা

18

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

পরিবর্তে, আমি একটি বিল্ড টুল (ম্যাভেন) ব্যবহার করি যা আপনি নতুন চেকআউট করার সময় এই ফাইলগুলির প্রাথমিক সংস্করণ তৈরি করতে পারে।


যথার্থ হতে: এমভিএন গ্রহ: গ্রহ একটি উপযুক্ত। ক্লাসপথ এবং .প্রজেক্ট উত্পন্ন করবে। আপনি এটি -ডাউনলোডসোর্সগুলি = সত্য এবং -ডাউনলোডজেভাদোকস = সত্যকে পাস করতে পারেন।
আলেকসান্দার দিমিত্রভ

আপনি সর্বদা উত্স এবং জাভাদোক ডাউনলোড করতে আপনার পম এগ্রিপ্স প্লাগইনটি কনফিগার করতে পারেন।
ক্রিস ভেস্ট

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

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

এছাড়াও, প্লাগইনগুলির ফলে সংঘটিত সংঘর্ষগুলি সংশোধন করা হচ্ছে যা এই ফাইলগুলিকে স্বল্পভাবে সম্পাদনা করে তাড়াতাড়ি পুরানো হয়ে যায়।
ক্রিস ভেস্ট

7

আমি এখানে দুটি বিকল্পের মধ্যে ছিঁড়ে গিয়েছি।

একদিকে, আমি মনে করি যে প্রত্যেকটি উত্স শৈল্পিক সংস্করণ নিয়ন্ত্রণে সংরক্ষণ করা হয় এবং বিল্ড স্ক্রিপ্ট (এএনটি বা ম্যাভেন বলুন) এর দ্বারা মান মেনে চলার বিষয়টি নিশ্চিত করে যতক্ষণ না সমস্ত উত্স শৈল্পিক সংস্করণ নিয়ন্ত্রণে সর্বাধিক উত্পাদনশীল সেগুলির সেটটি ব্যবহার করার জন্য প্রত্যেককে স্বাধীন হতে হবে think কোনটি জেডিকে ব্যবহার করবে তা নির্দিষ্ট করে, কোন তৃতীয় পক্ষের গ্রন্থাগারগুলির উপর নির্ভর করবে কোন স্ট্রোল চেক (উদাহরণস্বরূপ চেকস্টাইল) এবং চলমান ইউনিট পরীক্ষা ইত্যাদি versions

অন্যদিকে, আমি মনে করি যে অনেক লোক একই সরঞ্জামগুলি ব্যবহার করে (যেমন- Eclipse) এবং প্রায়শই বিল্ড টাইমের পরিবর্তে ডিজাইনের সময় কিছু জিনিস মানসম্মত করা আরও ভাল example উদাহরণস্বরূপ, চেকস্টাইল ইক্লিপ প্লাগইন হিসাবে অনেক বেশি কার্যকর একটি এএনটি বা ম্যাভেন টাস্ক - যে উন্নয়নের সরঞ্জামগুলির সেট এবং প্লাগইনগুলির একটি সাধারণ সেটকে মানিক করা ভাল is

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

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

পিএস যদি আপনি মাভেন ব্যবহার করেন তবে। প্রজেক্ট এবং। ক্লাসপাথ ফাইলগুলি নিদর্শনগুলি প্রাপ্ত বলে বলার পক্ষে একটি যুক্তি রয়েছে। এটি কেবল সত্য যদি আপনি প্রতিটি সময় কোনও বিল্ড তৈরি করার সময় এগুলি উত্পন্ন করেন এবং পিওএম থেকে উত্পন্ন করার পরে যদি আপনাকে কখনও তাদের হাতে ঝাঁকুনি দিতে হয় না (বা অজানাভাবে কিছু পছন্দ পরিবর্তন করে তাদের পরিবর্তন করা হয়)


6

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


5

না, আমি একজন ভারী মাভেন ব্যবহারকারী এবং গ্রহণের জন্য Q ব্যবহার করুন প্লাগইনের করি যা প্রজেক্ট এবং .classpath আপডেট করে keeps প্লাগইনগুলির জন্য সেটিংসের মতো অন্যান্য জিনিসের জন্য আমি সাধারণত এটি সম্পর্কে একটি README বা উইকি-পৃষ্ঠা মেন্টেন করি।

এছাড়াও আমি এর সাথে কাজ করেছি তারা অন্যান্য আইডিই পছন্দ করে কেবল তাদের আইডিই (এবং নিজেরাই) খুশি রাখতে প্রয়োজনীয় ফাইলগুলি তৈরি করতে ম্যাভেন-প্লাগইনগুলি ব্যবহার করে।


5

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

যেভাবেই হোক, আপনি অবশ্যই ব্যবহারকারীর সেটিংস সঞ্চিত রাখতে চান না - এবং .প্রজেক্টে এমন ডেটিং থাকতে পারে যা সত্যিই বিকাশকারী নির্দিষ্ট।

আমি মানভিন্ড বিল্ড সিস্টেম হিসাবে মাভেন বা পিঁপড়ার মতো কিছু ব্যবহার করার পরামর্শ দিচ্ছি। যে কোনও বিকাশকারী কয়েক সেকেন্ডের মধ্যে তাদের আইডিইতে একটি ক্লাসপথ কনফিগার করতে পারে।


1

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


1

যদিও আমি "উত্পন্ন ফাইলগুলিকে সংস্করণ দিই না" পদ্ধতির বিষয়ে সাধারণত একমত, আমাদের এতে সমস্যা আছে এবং আমাদের ফিরে যেতে হবে।

দ্রষ্টব্য: আমি ভনসির উত্তরের প্রতি আগ্রহী , বিশেষত "কয়েক মিনিটের মধ্যেই ग्रहण পান" পয়েন্ট সম্পর্কে। তবে এটি আমাদের পক্ষে সিদ্ধান্তমূলক নয়।

আমাদের প্রসঙ্গে এম 2 স্লিপস প্লাগ-ইন ব্যবহার করে Eclipse + Maven। আমাদের যথাসম্ভব সাধারণ ডিরেক্টরি সহ একটি বিকাশের পরিবেশ রয়েছে। তবে এটি কখনও কখনও ঘটে থাকে যে কেউ একটি প্লাগ-ইন চেষ্টা করবেন, বা কনফিগারেশনে সামান্য জিনিস পরিবর্তন করবেন, বা অন্য একটি শাখার জন্য দ্বিতীয় কর্মক্ষেত্র আমদানি করবেন ...

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

আমরা দেখতে পাই একমাত্র সমাধান হ'ল। প্রকল্প ফাইলটি সংস্করণ করা (ঝুঁকি এড়ানোর জন্য, আমরা .classpath এবং .setting এর জন্যও একই কাজ করব)। এইভাবে, যখন কোনও বিকাশকারী তার পম পরিবর্তন করে, স্থানীয় ফাইলগুলি এম 2 স্লিপস ব্যবহার করে আপডেট হয়, তারা সমস্ত একসাথে প্রতিশ্রুতিবদ্ধ হয় এবং অন্যান্য বিকাশকারীরা সমস্ত পরিবর্তন দেখতে পাবেন।

দ্রষ্টব্য: আমাদের ক্ষেত্রে আমরা আপেক্ষিক ফাইলের নাম ব্যবহার করি, সুতরাং সেই ফাইলগুলি ভাগ করতে আমাদের কোনও সমস্যা নেই।

সুতরাং, আপনার প্রশ্নের উত্তর দিতে, আমি হ্যাঁ বলছি, এই ফাইলগুলি প্রতিশ্রুতিবদ্ধ করুন।


আমিও পছন্দ করি:


"... m2eclipse ব্যবহার করে তার pom পরিবর্তন করে ..."? M2eclipse এর পম ফাইলের সাথে কী সম্পর্ক আছে? অবশ্যই এটি ব্যবহার করে তবে পমের পরিবর্তনগুলি প্লাগইন থেকে স্বতন্ত্র হওয়া উচিত।
আরএইচসিগার

@ আরএইচসিগার ধন্যবাদ, আমি আমার উত্তরের এই অংশে স্বচ্ছতার উন্নতি করব।
KLE

0

দেখে মনে হচ্ছে যে এই প্রকল্পের ফাইলগুলি সময়ের সাথে সাথে আপনি কোনও প্রকল্পে কাজ করতে পারেন তাই হ্যাঁ, আমি সেগুলি সংস্করণ নিয়ন্ত্রণে রাখি।



0

আমরা ইন্টেলিজ আইডিইএ ব্যবহার করি এবং প্রকল্পের।

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

ভাগ করা ও সংস্করণযুক্ত প্রকল্প ফাইলগুলির কিছু সুবিধা:

  • আপনি যে কোনও ট্যাগ / শাখা পরীক্ষা করে দেখতে পারেন এবং এটিতে দ্রুত কাজ শুরু করতে পারেন
  • নতুন বিকাশকারীকে প্রথমে বিকাশের পরিবেশ সেট আপ করা এবং গতিতে পৌঁছানো সহজ করে তোলে
  • এটি ডিআরওয়াইয়ের সাথে আরও ভালভাবে মেনে চলে, যা সর্বদা গভীরভাবে সন্তুষ্ট থাকে। এর আগে, সমস্ত বিকাশকারীকে এই জিনিসগুলি এখন এবং তারপরে সেট আপ করতে হয়েছিল, মূলত বারবার কাজ করা। অবশ্যই নিজের পুনরাবৃত্তি এড়ানোর জন্য প্রত্যেকেরই নিজস্ব ছোট ছোট উপায় ছিল, তবে সামগ্রিকভাবে দলের দিকে তাকালে অনেকগুলি নকল প্রচেষ্টা ছিল।

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

আমি এই উত্তরের সাথে একমত যা এই বলে:

আপনার অবশ্যই কোনও প্রকল্পকে একটি ওয়ার্কস্পেসে লোড করতে সক্ষম হতে হবে এবং এটি যথাযথভাবে আপনার আইডিইতে সেট আপ করতে এবং কিছুক্ষণের মধ্যে যেতে হবে আপনার যা কিছু আছে তা এতে থাকতে হবে। [...] এটি লোড করুন, সেট আপ করুন, যান।

সংস্করণযুক্ত প্রকল্প ফাইলগুলির জন্য আমাদের এটির মতো রয়েছে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.