Как расположить папки локально и в SVN при использовании eclipse

Question

Я много лет работал с eclipse и SVN в командах от одного разработчика до 12, и я всегда был тем, кто настраивал структуру наших папок. Мне удалось как-то заставить его работать, но я чувствую, что расположение моей папки далеко от оптимального. Трудно сказать, как выглядел мой типичный макет папки, потому что каждый раз он выглядел совсем по-другому.

Сейчас я только начинаю еще один большой проект, и я хочу сделать это на профессиональном уровне на этот раз.

Факты о проекте

Это факты прямо сейчас:

• Все разработчики будут работать с Eclipse
• Некоторые будут использовать Subclipse для интеграции SVN в Eclipse, другие будут использовать внешние клиенты, такие как Tortoise SVN или svnX
• мы разрабатываем для Windows и Mac OS
• мы используем муравей для автоматизации сборки и тестирования junit
• будет несколько взаимосвязанных проектов:
  • библиотека, написанная на чистом Java, поэтому она работает на всех известных платформах Java
  • несколько приложений для нескольких платформ Java (J2SE, J2ME, android ...). Все эти приложения зависят от библиотеки, упомянутой ранее

Что делать с .project?

Я всегда не уверен, что нужно фиксировать эти файлы, сгенерированные eclipse (например, '.project' и '.classpath'). В предыдущих проектах иногда мы помещали их в SVN, иногда нет, и оба подхода имели свои плюсы и минусы. Когда-то мы даже использовали целое рабочее пространство, но это казалось плохой идеей.

Одна ключевая концепция, которую мне, безусловно, не хватает, - это то, как Eclipse обрабатывает свое рабочее пространство. По умолчанию весь проект находится в папке рабочей области, но могут быть проекты, которые являются внешними, которые связаны каким-то волшебным способом, который я просто не понимаю.

Возможные макеты папок

Я не уверен, как разместить проект локально и в хранилище. Я думаю, что есть три варианта:

• рабочая область - это подпапка моей локальной рабочей копии (например, c: \ code \ myWorkingCopies \ projectXyz \ trunk \ workspace)
• мое рабочее пространство - моя рабочая копия (я использую c: \ code \ myWorkingCopies \ projectXyz \ trunk \ в качестве рабочего пространства)
• Моя рабочая область находится где-то (c: \ code \ workspace), а моя рабочая копия где-то еще (c: \ code \ myWorkingCopies \ projectXyz \ trunk), и у меня есть эти внешние проекты
• есть еще идеи?

Какой ответ я ищу?

Фиктивная структура папок, может быть что-то в этом роде (я просто отвечаю на свой вопрос?):

• Ствол
  • проекты
    • Projecta
    • projectB

Вместе с подсказкой, где оформить заказ, вот так:

• извлечение ствола / проектов в c: \ code ...)

И некоторые рекомендации, такие как

• никогда не загружать файлы типа x, y, z ...

Answer 1

Рабочие пространства и репозитории не должны быть связаны.

В рабочей области Eclipse хранит множество настроек. Файлы проекта могут (и обычно имеют) жить в рабочей области, но, как вы знаете, они могут быть импортированы из внешнего источника - импорт - это просто логическая ссылка.

Вы можете создать столько рабочих пространств, сколько захотите для определенных целей; Вы даже можете импортировать проекты из одного рабочего пространства в другое, если у вас есть для этого причина.

Расположение SVN должно быть отдельным от того, как определено ваше рабочее пространство. Они могут выглядеть похожими, но это не означает, что они на самом деле одинаковы. Я бы рекомендовал каждому проекту Eclipse иметь свой собственный проект SVN, чтобы вместо

• http://myrepo
  • myworkspace
    • Ствол
      • Projecta
      • projectB
    • метка

у вас есть

• http://myrepo
  • Projecta
    • багажник
    • метка
    • филиалы
  • projectB
    • багажник
    • метка

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

Последний вопрос о том, какие артефакты нужно проверять в SVN, является вопросом вкуса. Я бы порекомендовал проверить, какие артефакты универсальны для всей команды разработчиков. Если Eclipse - это стандартная среда IDE, проверьте файлы .project и .classpath, чтобы новый разработчик мог сразу же оформить заказ и выполнить сборку. Если некоторые плагины универсальны и имеют собственные конфигурационные файлы, проверьте их. С другой стороны, все, что не используется в команде разработчиков, должно быть исключено из репозитория.

Надеюсь, это поможет.

---

EDIT

Дальнейший опыт научил меня, что единственными вещами, которые должны входить в систему контроля версий, являются фактические исходные файлы. Файлы конфигурации и настройки должны быть восстановлены разработчиком при настройке нового проекта.

Answer 2

У нас похожая настройка (для пользователей Mac, Linux и Windows), и наша структура папок:

• Ствол
  • код
    • Projecta
    • projectB

Мы проверяем файлы .project, .settings и .classpath, а также код, но НЕ рабочие пространства. Настоящие ошибки связаны с путями сборки. Если вы решите их, то у вас не будет головной боли и нет требований относительно того, в каких каталогах нужно проверять.

Несколько советов:

1. Если ваши проекты ссылаются друг на друга, убедитесь, что они ссылаются друг на друга, используя вкладку «Проекты» пути сборки. При этом все ссылки на другие проекты будут относительными (../projectA, а не / opt / trunk / projectA, что нарушит проекты других людей).
2. Если у вас есть какие-либо внешние библиотеки, на которые вы ссылаетесь, создайте пользовательские библиотеки и сделайте так, чтобы все создавали библиотеки с одинаковыми именами. Мы используем JBoss, поэтому мы заставляем всех создавать пользовательскую библиотеку под названием JBoss, которая ссылается на файлы jar в своей локальной установке JBoss. Таким образом, не имеет значения, где установлен ваш JBoss, если у вас есть эта пользовательская библиотека, вам будет хорошо. Ваш проект будет ссылаться на имя библиотеки пользователя, но фактическая информация о библиотеке пользователя является локальной для каждого пользователя.
3. Убедитесь, что все знают о советах № 1 и 2. Единственный случай, когда все облажается, это когда кто-то забывает делать ссылки через вкладку «Проект» вместо того, чтобы просто ссылаться на банку напрямую.

Все это работает с плагинами Eclipse SVN или без.

Answer 3

Я использую, и настоятельно рекомендую структуру хранилища что-то вроде:

• Проекты
  • ProjectA
    • Ствол
      • Java
      • HTML
      • * 1014 документы *
      • конф
• Продавец
  • JUnit
    • ток
    • 1,1

На диске используйте макет вроде:

c:\dev\
   \ProjectAtrunk\
   \ProjectBbranch4\

Работая таким образом, ваши ветви и теги находятся рядом с вашими стволами, и вы вряд ли будете зависеть от структуры проектов в вашем хранилище для ссылок на внешние библиотеки. Все ссылки на код вне ствола проекта должны использовать внешние символы.

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

Вы можете больше просматривать изменения в стволе проекта и видеть полную историю вашего проекта без мусора. Вы с меньшей вероятностью будете иметь изменения в своем проекте, которые не будут видны при просмотре истории изменений в транке.

При выпуске используйте стабильные ветки и svn-merge.

Answer 4

В Macromedia Dreamweaver и Eclipse я делал следующее:

Working folder: 
C:\Development\
    \ProjectA
    \ProjectB
    \ProjectC

Каждый проект имеет свой собственный репозиторий, и каждая проверка имеет только /trunk/.

Примечание. Для Eclipse не создавайте проект репозитория SVN, просто создайте проект "Java App" или "PHP App", как вы это обычно делаете, и используйте внешнюю программу для выполнения извлечения в эту папку. Затем Eclipse автоматически обнаружит информацию .svn и позволит вам использовать инструменты SVN, в то же время используя правильное рабочее пространство.

Answer 5

Икстер говорит: «... но, как вы знаете, их можно импортировать из внешнего источника - импорт - просто логическая ссылка».

На самом деле, это не совсем так. Импорт выполняет копирование, тогда как связанный ресурс - это ссылка на структуру внешнего источника. Увидеть: Связанные ресурсы а также Создание связанных ресурсов

Answer 6

Я недавно начал использовать Subclipse и у меня есть метод, который работает для меня. Мы работаем с приложениями PHP, поэтому я создаю новый проект SVN с помощью мастера проектов Eclipse, выбрав «Проверять проекты через SVN». Затем я настраиваю этот проект с помощью мастера настройки проекта и выбираю PHP в качестве типа проекта. Я называю проект так, чтобы в моей рабочей области имя проекта находилось на верхнем уровне проводника проекта.

Я никогда не совершаю ничего, что создано специально для Eclipse, тем более что не все в нашей команде используют Eclipse. Это означает исключение файлов .project и любых других файлов, созданных Eclipse.

Дополнительным преимуществом использования этого метода является то, что в рабочую область может быть добавлено более одного хранилища. Мы работаем с двумя хранилищами для нашего проекта (по конкретным причинам, в которые я не буду вдаваться), поэтому мне легко и удобно работать над обоими «проектами» одновременно.

Я уверен, что есть другие способы сделать это, но я обнаружил, что это самый простой способ использовать Subversion и Eclipse.