Структура репозитория SVN - почему это лучше? - PullRequest
14 голосов
/ 31 июля 2009

Мне сказали, что большинство магазинов разработки имеют следующую структуру или, по крайней мере, близки к этому:

  • Главный репозиторий
    • Папки проекта под
    • В каждой папке проекта есть папка с стволами, ветками и тегами

так:

ReponsitoryMain
    Project1
        branches
        trunk
        tags
    Project2
        ...

Так почему же это лучше или лучше? Что происходит или с какими страданиями вы сталкиваетесь, если делаете это по-другому?

Ответы [ 10 ]

17 голосов
/ 31 июля 2009

Большинство людей делают это, потому что это рекомендуется Subversion book .

Вот хорошее объяснение от директора проекта CollabNet Subversion:

http://blogs.collab.net/subversion/2007/04/subversion_repo/

14 голосов
/ 31 июля 2009

Это способ организации хранилища:

ReponsitoryMain
    Project1
        branches
        trunk
        tags
    Project2
    ...

лучше всего, когда ваши проекты не связаны или зависят друг от друга. С другой стороны, упрощается версия всего пакета проекта. Поэтому, если вы часто выпускаете / упаковываете Project1 и Project2 вместе, лучше всего, чтобы они совместно использовали одну и ту же ветку.

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

9 голосов
/ 31 июля 2009

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

trunk
   prj_a
   prj_b
tags
   <YOUR_TAGNAME>
       prj_a
       prj_b
branches
   <YOUR_BRANCHNAME>
     prj_a
     prj_b

или что-то еще, что имеет больше смысла для вашего процесса.

В простой структуре с локальными стволом / тегами / ветвями невозможно (по крайней мере, чисто) пометить несколько проектов, если между ними есть зависимости.

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

Основная проблема в том, что в SVN НЕТ поддержки общих ресурсов и их тегирования / ветвления.

Если вы думаете о своей структуре репозитория, вам следует спросить себя, в каком процессе вы хотите поделиться своими библиотеками кода.

7 голосов
/ 06 августа 2009

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

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

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

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

Этот вид ссылки имеет 3 эффекта: 1 Ваш проект изолирован от случайных промежуточных изменений разработки библиотеки. 2 вы получаете ревизию в вашем проекте , которая говорит вам, что «я сейчас использую эту версию библиотеки». 3. Когда вы вносите изменения в свой проект, вы получаете контроль, чтобы учесть любые критические изменения в библиотеке.

Есть и другие проблемы, которые я могу решить, если этого недостаточно.

5 голосов
/ 31 июля 2009

Мы храним отдельный репозиторий для каждого проекта.

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

2 голосов
/ 06 августа 2009

В моем магазине у нас есть что-то вроде этого:

RepositoryMain
  Trunk
    proj 1
    proj 2
    ..
  Dev
    Team1
      proj 1
      proj 2
    Team2
      proj 1
      proj 2
    ...

Я не знаю, как это складывается в большинстве мест, но, кажется, работает довольно хорошо

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

2 голосов
/ 31 июля 2009

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

М.

1 голос
/ 06 августа 2009

В таких системах, как CVS, у вас не было отдельных «каталогов». Вы только что отметились и разветвились.

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

1 голос
/ 31 июля 2009

Магистральные ветви и теги действуют одинаково. Как вы используете их, зависит от вас.

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

0 голосов
/ 05 июля 2012

Спасибо за обсуждение здесь, я прошел через это и структура проекта для продукта с разными версиями

link2

link3

link4

Я видел, что терминология сбивает с толку. Проекты, Приложения, чтобы правильно соотнести

Хотел бы повторить вышеизложенное с несколько ясным опытом Допустим, мы делаем решение для клиента ABC Решением является приложение TIcket / HelpDesk для запросов клиентов ABC

Допустим, applicationName является OneDeskApplication. Это приложение состоит из WebUI, общие библиотеки, инструменты сборки

можем ли мы спроектировать SVN следующим образом

XSoftware.com / ABC - Репозиторий / хобот/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp ветви/ Branch_Product_Support_1_0_0_0 / OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp теги / OneDeskDocs OneDeskMasterBuild

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...