Проверка проекта Eclipse в SVN

Question

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

• ЦСИ
• WebContent
• сборки
• расстояние
• build.xml
• .project
• .classpath
• . Установки/

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

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

EDIT:

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

** EDIT 2 **

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

• .project
• .settings/
• .classpath

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

Answer 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.projecttarget (выходной каталог по умолчанию для Maven2) и любые другие сгенерированные материалы (файлы журналов, gfembed-каталоги и т. Д.). В вашем случае вы проигнорируете build и dist вместо target.

Файлы или каталоги svn-ignore с RIGHT_MOUSE->Team->'Add to svn:ignore' (я использую плагин Subclipse). Игнорировать инструкции хранятся как svn-properties в родительском каталоге. Свойства в каталоге могут быть просмотрены RIGHT_MOUSE->Team->Show properties. Вы также можете редактировать свойства непосредственно там, щелкнув поле значения. Убедитесь, что после каждого свойства есть конец строки.

Теперь, когда вы уже зафиксировали и удалили эти файлы, игнорирование в моем опыте больше не будет работать. Как-то мне никогда не удавалось успешно игнорировать сгенерированные файлы, которые когда-либо проверялись в репозитории SVN; они похожи на зомби, всегда возвращающихся из мертвых. Возможно, удалив их записи физически в репо SVN, это может быть достигнуто, но я этого никогда не делал.

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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