Які файли Eclipse належать до контролю версій?

Які файли Eclipse доцільно поставити під контроль джерел, окрім джерел, очевидно?

У моєму проекті, зокрема, мені цікаво:

.metadata / *
project-dir / .project
project-dir / .classpath
project-dir / .settings / *

Якщо є якісь із них, від яких це залежить, будь ласка, поясніть свої вказівки.

Метаданими не слід керувати в контролі джерел. Вони містять в основному дані, що стосуються вашої робочої області.

Єдиним винятком є .launchфайли XML (визначення запуску).

Вони знайдені в

[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches

І вони повинні бути скопійовані у ваш каталог проектів: Коли ваш проект буде оновлено, ці конфігурації відображатимуться у діалоговому вікні «Запустити конфігурацію».

Таким чином, тими файлами параметрів запуску також можна керувати в SCM.

(Увага: зніміть опцію «Видаляти конфігурації , коли пов'язаний ресурс видалений» в Run / Запуск / Конфігурація Запуск панелі уподобань: він є загальним для м'якого видалення проекту для того , щоб імпортувати його назад - щоб змусити переініціалізація метадані eclipse. Але якщо це встановлено, цей параметр видалить ваші детальні параметри запуску!)

project-dir/.project
project-dir/.classpath
project-dir/.settings/* 

має бути у вашій SCM (особливо .projectта .classpathвідповідно до документації Eclipse ).

Мета полягає в тому, що кожен може перевірити / оновити свою робочу область SCM та імпортувати проект Eclipse в робочу область Eclipse.

Для цього ви хочете використовувати лише відносні шляхи у своєму .classpath, використовуючи пов'язані ресурси .

Примітка: краще, якщо project-dirпосилається на "зовнішній" каталог проектів, а не на каталог, створений у робочій області eclipse. Таким чином, два поняття (затемнення робочої області проти робочої області SCM) чітко розділені.

Як згадує ipsquiggle у коментарі, і як я вже нагадав у старій відповіді , ви можете фактично зберегти конфігурацію запуску як спільний файл безпосередньо у каталозі проекту. Після цього всю конфігурацію запуску можна виконати як інші файли проекту.

(З допису в блозі Порада: Створення та спільний доступ до конфігурацій запуску від KD)

Зараз я працюю над проектом, де у нас є файли .project та .cproject під контролем джерела. Ідея полягала в тому, що налаштування, пов’язані з бібліотечними шляхами та директивами про посилання, поширюватимуться в команді.

На практиці це не спрацювало дуже добре, злиття майже завжди повертаються в конфліктний стан, який потрібно знеструмити поза затемненням, а потім проект закрити і знову відкрити, щоб зміни вступили в силу.

Я б не рекомендував тримати їх у контролі джерел.

Нічого не варто, що файли конфігурації CDT не є зручними для контролю джерел. Там подано помилку для .cproject-файлів, які змінюються дуже часто і викликають конфлікти, див. Спільний доступ до файлів cdt-проекту у сховищі завжди викликає конфлікти .

Деякі проекти, як-от такі, що використовують Maven, люблять генерувати файли .project на основі POM.

Однак, крім цього - .метадані НЕ повинні знаходитись у контролі джерел. Ваш проект повинен визначитися, чи робить projectdir / .settings, виходячи з того, як ви плануєте керувати стандартами та ін. Якщо ви можете чесно довіряти своїм розробникам, щоб створити їхнє середовище на основі стандарту, і вам не потрібно налаштовувати нічого особливого для будь-якого проекту, тоді вам не потрібно їх вносити. Мені, я рекомендую налаштувати кожен проект конкретно . Це дозволяє розробникам працювати над кількома проектами в одній робочій області, не змінюючи налаштування за замовчуванням вперед і назад, і це робить налаштування дуже чіткими, переосмислюючи всі налаштування за замовчуванням, щоб відповідати стандартам проекту.

Тільки складна частина полягає в тому, щоб усі вони залишалися синхронізованими. Але в більшості випадків ви можете скопіювати файли .settings з проекту в проект. Якщо в контролі джерела є якісь конкретні ви не хочете, виконайте еквівалент налаштування svn: ігноруйте їх, якщо ваш SCM це підтримує.

Файл .classpath, безумовно, є хорошим кандидатом для перевірки в scm, оскільки його встановлення вручну може бути багато роботи і буде важким для нових розробників, які потраплять у проект. Це правда, що його можна генерувати з інших джерел, і в такому випадку ви перейдете до іншого джерела.

Що стосується .установок, це залежить від налаштувань. Це сіра зона, але деякі налаштування майже обов'язкові, і зручно мати можливість перевірити проект, імпортувати його в Eclipse і мати все, що налаштовано, і добре.

Тому в нашому проекті ми підтримуємо копію папки .settings під назвою CVS.settings, і ми маємо завдання мурашки скопіювати її у .settings. Коли ви отримуєте проект із CVS, ви викликаєте завдання "eclipsify" ant, щоб скопіювати налаштування за замовчуванням у нову папку .settings. Коли ви налаштовуєте налаштування, необхідні всім, хто розробляє проект, ви об'єднуєте їх назад у папку CVS.settings і передаєте їх CVS. Таким чином збереження налаштувань у SCM стає усвідомленим процесом. Тут потрібні розробники, щоб час від часу об'єднувати ці налаштування у свої папки з налаштуваннями, коли перевіряються великі зміни. Але це проста система, яка працює на диво добре.

Я б сказав, що жоден з них. Вони, швидше за все, містять інформацію, що стосується лише вашої робочої станції (я думаю про шляхи до бібліотек та всіх). Також що робити, якщо хтось із вашої команди не використовує Eclipse?

Поміркуйте:

.classpath
.project
.launch

Ці ОСОБЛИВО мати контроль над версіями до тих пір, поки ви дотримуєтесь використання шляхів відносно проекту. Це дозволяє іншим розробникам перевірити проект і почати працювати відразу, не переживаючи всі болі за налаштування, які пройшли також інші розробники.

Ви можете спокусити включити .metadata до контролю версій, щоб розробники Eclipse могли перевірити цілу робочу область і заздалегідь налаштувати всі потрібні проекти, але вона включає в себе багато інформації, що відповідає користувачеві, що будь-коли хтось над цим працює, це буде зміни, тому я б радив НЕ ВКЛЮЧАТИ .метадані. Побудувати локальну робочу область просто, імпортуючи всі існуючі проекти Eclipse.

Я витратив занадто багато годин на налаштування параметрів робочої області затемнення для нових колег (і для себе). Що в кінцевому підсумку я зробив, це скопіювати власні .metaдані на нову машину розробника.

Якщо ви працюєте над командою, я вважаю, що наступні дуже хороші кандидати, які слід тримати під контролем версій:

• Встановлено JRE та їх назви
• Середовище виконання сервера
• Шаблони редактора Java
• Комбінації клавіш для управління версіями
• Налаштування плагіна, які не передбачають конкретних параметрів проекту
• Налаштування Maven
• Попередньо налаштовані перспективи
• ...