Проверка в проекте Eclipse в SVN - PullRequest
15 голосов
/ 19 августа 2010

Я хочу проверить динамический веб-проект, который я создал в eclipse, в svn.Может кто-нибудь сказать мне, какие файлы я должен проверить, а какие нет?Идея состоит в том, чтобы иметь возможность проверить проект с помощью мастера создания проекта, чтобы я мог снова создать динамический веб-проект.Более конкретно, вот файлы / каталоги, которые у меня есть в проекте -

  • src
  • WebContent
  • build
  • dist
  • build.xml
  • .project
  • .classpath
  • .settings /

Очевидно, что каталог сборки не проверяется.А как насчет других?Я угадал все.файлы не должны быть проверены в.Кто-нибудь может это проверить?Что это за каталог dist и каталог .settings?

Кроме того, где eclipse хранит информацию о сервере (tomcat)?Я не хочу проверять это либо.

РЕДАКТИРОВАТЬ:

Я изначально проверил все вышеперечисленное, кроме каталога сборки, конечно.Когда я извлек проект из Eclipse, он не побудил меня создать новый проект, так как .project есть, но Eclipse создавал проект JavaEE или что-то вместо Dynamic Web Project.Кто-нибудь еще сталкивался с таким поведением?

** РЕДАКТИРОВАТЬ 2 **

Найдено!Оказывается, я не должен проверять следующее -

  • .project
  • .settings /
  • .classpath

После этих3 удалены Мастер нового проекта работает, как и ожидалось, и все в порядке.

Ответы [ 4 ]

13 голосов
/ 19 августа 2010

Если вы отметите .classpath/.project/.settings, вы сделаете свой проект специфичным для Eclipse. А как насчет разработчиков, которые работают с Netbeans или IntelliJ? ИМО, чище поддерживать независимость вашего IDE от проекта и легко настраивать.

Я обычно хожу на сборку Maven. pom.xml определяет все необходимые зависимости, а mvn eclipse:eclipse создает файлы .classpath/.project для вас.

Каталог .settings содержит локальные настройки (например, какую версию Java вы хотите использовать). IMO, это не полезно проверять это. Вы можете обеспечить соответствие версии 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, этого можно добиться, но я никогда этого не делал.

11 голосов
/ 19 августа 2010

В нашем случае мы отметили все, что вы упомянули в списке, за исключением .settings /.

С .classpath и .project пользователи могут быстро проверить проект и запуститьЗатмение на новом компьютере и просто начать работать на нем;альтернатива заключается в том, чтобы настроить проект вручную и тщательно добавить все зависимости jar (если вы используете ant).Многие проекты с открытым исходным кодом делают это.

Прочитайте это , есть некоторые действительно хорошие моменты, о которых стоит задуматься.

2 голосов
/ 19 августа 2010

Хороший вопрос ... Многие из нас сталкиваются с проблемой, хотим ли мы проверить файлы, связанные с IDE, или нет. Обычно я проверяю eclipse в .classpath и использую переменные eclipse, чтобы убедиться, что команде нужно просто изменить значение переменной, и она работает. Мы также регистрируем .project, чтобы команда не создавала новый проект в своей рабочей области.

0 голосов
/ 19 августа 2010

Я бы пропустил .project, .settings /, dist и build.

.classpath можно оставить, если вы используете переменные вместо жестко закодированных путей. Это полезно, так что вам не нужно перестраивать ваш classpath каждый раз, когда вы проверяете проект.

...