Проверка проекта Eclipse в SVN
Я хочу проверить динамический веб-проект, который я создал в eclipse, в svn. Может кто-нибудь сказать мне, какие файлы я должен проверить, а какой я не должен? Идея состоит в том, чтобы иметь возможность проверить проект с помощью мастера создания проектов, чтобы снова создать проект Dynamic Web Project. Более конкретно здесь находятся файлы/каталоги, которые у меня есть в проекте -
- ЦСИ
- WebContent
- построить
- расстояние
- build.xml
- .project
- .classpath
- .settings/
Каталог сборки не должен проверяться, очевидно. А как насчет других?
Я угадываю все. файлы также не должны проверяться. Можно ли это проверить?
Что это за каталог dist и каталог .settings?
Также где eclipse хранит информацию о сервере (tomcat)? Я также не хочу проверять его.
EDIT:
Первоначально я проверял все вышеперечисленное, кроме каталога сборки. Когда я проверил проект изнутри Eclipse, он не предлагал мне создать новый проект, поскольку существует .project, но Eclipse создавал проект JavaEE или что-то вместо Dynamic Web Project. Кто-нибудь еще сталкивался с этим поведением?
** РЕДАКТИРОВАТЬ 2 **
Нашел! Оказывается, я не должен проверять следующее -
- .project
- .settings/
- .classpath
Как только эти 3 будут удалены, мастер создания проекта будет работать так, как ожидалось, и все в порядке.
Ответы
Ответ 1
Если вы зарегистрируетесь в .classpath/.project/.settings
, вы создаете свой проект Eclipse. Что относительно разработчиков, которые работают с Netbeans
или IntelliJ
? ИМО чище, чтобы ваш проект был IDE-независимым и легким в настройке.
Обычно я собираюсь построить Maven. pom.xml
указывает все необходимые зависимости, а mvn eclipse:eclipse
генерирует файлы .classpath/.project
для вас.
Каталог .settings
содержит локальные настройки (например, какую версию Java вы хотите использовать). ИМО нецелесообразно проверять это. Вы можете обеспечить соответствие Java-версии через maven2 pom.
Наконец, для вашего следующего проекта мой прогип - это svn-ignore
файлы или каталоги, которые вы не хотите в SVN до, ваш первый коммит. В настройке Maven2, которая будет .settings
.classpath
.project
target
(выходной каталог по умолчанию для Maven2) и любые другие сгенерированные материалы (файлы журналов, gfembed-каталоги и т.д.). В вашем случае вы игнорируете build
и dist
вместо target
.
Вы можете svn-ignore
файлы или каталоги с помощью RIGHT_MOUSE->Team->'Add to svn:ignore'
(я использую плагин Subclipse). Игнорировать инструкции хранятся как svn-properties
в родительском каталоге. Свойства в каталоге можно просмотреть с помощью RIGHT_MOUSE->Team->Show properties
. Вы также можете редактировать свойства непосредственно там, щелкнув поле значения. Убедитесь, что после каждого свойства есть конец строки.
Теперь, когда вы уже зафиксировали и удалили эти файлы, игнорирование в моем опыте больше не будет работать. Как-то мне никогда не удавалось успешно игнорировать сгенерированные файлы, которые когда-либо проверялись в репозитории SVN; они похожи на зомби, всегда возвращающихся из мертвых. Возможно, удалив их записи физически в репо SVN, это может быть достигнуто, но я этого никогда не делал.
Ответ 2
В нашем случае мы проверили все, что вы упомянули в списке, кроме,.settings/.
При проверке .classpath
и .project
пользователи могут быстро проверить проект и запустить Eclipse на новом компьютере и только начать работать над ним; альтернативой является настройка проекта вручную и кропотливое добавление во всех зависимостях банки (если вы используете ant). Многие проекты с открытым исходным кодом делают это.
Прочитайте это, есть некоторые действительно хорошие моменты, чтобы обдумать.
Ответ 3
Хороший вопрос... Многие из нас находятся в дилемме о том, хотим ли мы проверить файлы, связанные с IDE, или нет. Я обычно хожу для проверки в .classpath для eclipse, и я использую переменные eclipse, чтобы убедиться, что команде нужно просто изменить значение переменной, и она работает. Мы также проверяем .project, чтобы команде не нужно было создавать новый проект в своей рабочей области.
Ответ 4
Я бы опустил .project,.settings/, dist и build.
.classpath может быть оставлен, если вы используете переменные вместо жестко заданных путей. Это полезно, поэтому вам не нужно перестраивать свой путь к классу каждый раз, когда вы просматриваете проект.