У меня есть проект Java, который я хотел бы передать в мой SVN-репозиторий, созданный с помощью eclipse.
Теперь, какие файлы (кроме исходного кода, очевидно) необходимы? В корневой папке рабочей области есть папка .settings со многими файлами и подпапками, а внутри папки проекта есть два файла:.classpath и .project, а другая папка .settings с одним файлом - org.eclipse.jdt.core.prefs.
Какой из этих файлов должен быть привязан к SVN и который можно безопасно исключить?
Все они полезны, если вы хотите иметь согласованные настройки в своей команде.
.classpath и .project означают, что каждый может встать и работать с проектом, просто импортировав его. Любые изменения в библиотеках и исходных файлах, включенных в проект, будут подхвачены всеми, когда они будут отмечены.
В каталоге .settings есть такие вещи, как параметры форматирования кода и то, что компилятор рассматривает как предупреждения, ошибки или ОК. Для согласованности я тоже начал проверять их (пока все в вашей команде могут согласиться на стандарт форматирования, я думаю).
Я обнаружил, что наибольшее ограничение при совместном использовании элементов управления версиями в Eclipse - в определениях библиотек. Определения библиотек, по-видимому, хранятся только для каждого пользователя, поэтому, если вы ссылаетесь на "библиотеку" в файле .classpath, каждый другой пользователь должен вручную определить содержимое этой библиотеки (или вручную импортировать файл экспортированных библиотек).
Изменить: (адресация комментария @mliebelt ниже)
Вы только фиксируете файлы .settings, если пытаетесь сохранить согласованность/стандартизацию между разработчиками. Если это не проблема для проекта, то не делать файлы .settings - это меньше всего беспокоиться о сохранении. Файлы, которые относятся к отдельным любимым плагинам, возможно, также не нужно совершать (хотя я не думаю, что это было бы больно, если бы они были, вероятно, были бы проигнорированы?).
Двумя наиболее распространенными из них, которые я нашел заслуживающими, являются org.eclipse.jdt.core.prefs и org.eclipse.jdt.ui.prefs, которые являются ядром для любого проекта (Java) Eclipse.
Вы можете исключить папку .settings, но файл .project будет полезен другим разработчикам, которые хотят восстановить тот же самый проект Eclipse. Если вы исследуете файл, он должен иметь только относительные ссылки (если это не так, вы должны изменить его как таковой.)
В отличие от других ответов, я улучшил опыт не проверять файл .project в больших проектах с открытым исходным кодом, с которыми я работаю.
Вы можете не соглашаться со мной, но есть одна проблема с общими файлами .project: они содержат ссылки на натуры проекта, используемые в проекте. Природа проекта снова зависит от плагинов, установленных на локальной машине разработчиков.
Пример. Если вы используете Findbugs в проекте Java, в ваш проект Java добавляется новый характер. Проверка этого файла, изменение его в другой системе (без установки Findbugs) и последующее использование его в моей системе снова привели к тому, что ссылка на Findbugs была потеряна для меня (и, следовательно, все проверки Findbugs были удалены молча).
Но если вы можете согласиться с тем, что все ваши разработчики согласятся использовать одни и те же инструменты, вы можете легко решить эту проблему.