Подтвердить что ты не робот

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Ствол
    • Проекты
      • Projecta​​li >
      • projectB

Наряду с подсказкой, что проверить, где, например:

  • checkout trunk/projects to c:\code...)

И некоторые ориентиры, такие как

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

ОТВЕТЫ

Ответ 1

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

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

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

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

  • http://myrepo
    • myworkspace
      • Ствол
        • Projecta​​li >
        • projectB
      • теги
      • ветки

у вас есть

  • http://myrepo
    • Projecta
      • багажник
      • теги
      • ветки
    • projectB
      • багажник
      • теги
      • ветки

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

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

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

ИЗМЕНИТЬ

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

Ответ 2

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

  • Ствол
    • код
      • Projecta​​li >
      • projectB

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

Некоторые советы:

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

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

Ответ 3

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

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

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

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

Ответ 4

Я использую и настоятельно рекомендую структуру репозитория примерно так:

  • Проекты
    • ProjectA
      • Ствол
        • ява
        • HTML
        • документы
        • конф
  • Vendor
    • JUnit
      • текущий
      • 1.1
      • 1.2

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

c:\dev\
   \ProjectAtrunk\
   \ProjectBbranch4\

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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