Мне сказали, что большинство магазинов развития имеют следующую структуру или, по крайней мере, близко к этому:
так:
ReponsitoryMain
Project1
branches
trunk
tags
Project2
...
Так почему это лучше или лучше? Что происходит, или какие страдания вы испытываете, если вы сделали это по-другому?
Этот способ организации репозитория:
ReponsitoryMain
Project1
branches
trunk
tags
Project2
...
лучше всего, когда ваши проекты не связаны/зависят друг от друга. Другим способом упростить версию всего пакета проектов. Поэтому, если вы часто выпускаете/объединяете Project1 и Project2 вместе, лучше всего, чтобы они делили одну ветвь.
Если, с другой стороны, ваш проект очень развязан, и у них работают совершенно разные команды, тогда вам не нужно будет проверять их всех вместе большую часть времени, и поэтому вы можете использовать вышеупомянутый метод.
Большинство людей делают это, потому что оно рекомендовано книгой Subversion.
Вот хорошее объяснение директора проекта Subabersion CollabNet:
Структура репозитория зависит от ваших потребностей. Если ваши проекты полностью разделены (без зависимостей между ними), то эта "простая" структура репозитория в порядке. Если у вас есть зависимости в вашем проекте (например, некоторые глобальные "библиотеки инструментов", общий код), вы должны использовать другую структуру, например:
trunk
prj_a
prj_b
tags
<YOUR_TAGNAME>
prj_a
prj_b
branches
<YOUR_BRANCHNAME>
prj_a
prj_b
или что-нибудь еще, что имеет смысл для вашего процесса.
В простой структуре с локальными соединительными линиями/тегами/ветвями невозможно (по крайней мере чистым способом) тегировать несколько проектов, если у вас есть зависимости между ними.
Также часто предлагаемый подход "Multi-repository" не заполняет этот пробел, поскольку тогда вы обречены на несколько ревизий или тегов в нескольких хранилищах.
Основная проблема заключается в том, что SVN поддерживает НЕТ для общих ресурсов ricesources и помечает/разветвляет их.
Если вы думаете о своей структуре репозитория, вы должны спросить себя, в каком процессе вы хотите поделиться своими кодовыми библиотеками.
Хорошо, я собираюсь быть немного более преданным и твердо встать на сторону наличия сундука, тегов и ветвей для каждого проекта.
Основной альтернативой является наличие одной соединительной линии, тегов и ветвей со всеми проектами внизу. Однако это приводит к ряду проблем, одна из которых значительна, и я подробно расскажу здесь:
В первую очередь это прокладывает путь к неприкосновенной библиотеке, где все боятся касаться определенной библиотеки, потому что любое изменение может сломать что-то тонкое в каком-то случайном проекте. Причиной этого является то, что, поскольку между проектами нет разделения, каждый может эффективно изменять код в своем проекте, не имея возможности обнаруживать или контролировать его.
Что происходит, так это то, что когда-нибудь вы проверите свой проект, и он будет создан, на следующий день вы его проверите, и он не сработает, но вы не внесли никаких изменений в свой проект. Случилось так, что кто-то изменил библиотеку, на которую вы зависели. В большой структуре со многими зависимостями нереалистично, чтобы разработчик тестировал свои изменения в библиотеке по отношению к каждому проекту, особенно если они должны были прервать изменения. Что вам нужно в вашем проекте, это ссылка на конкретную версию библиотеки. Таким образом, библиотека обновляется только при изменении ссылки на последнюю версию.
Эта ссылка имеет 3 эффекта: 1 ваш проект изолирован от случайных промежуточных изменений разработки в библиотеке. 2 вы получаете ревизию в своем проекте, которая сообщает вам, что "я сейчас использую эту версию библиотеки". 3. Вы получаете возможность контролировать, когда вы вносите изменения в свой проект, чтобы учесть любые нарушения в библиотеке.
Есть и другие проблемы, которые я могу пройти, если этого недостаточно.
Мы сохраняем отдельный репозиторий для каждого проекта.
Хотя это не позволяет копировать и сохранять файлы истории версий из одного проекта в другой, он позволяет вам архивировать весь репозиторий, когда проект завершен.
Что мы имеем. Он работает и до сих пор достаточно хорош (потому что мы никогда не знаем, что принесет будущее) У нас нет веских причин потратить некоторое драгоценное время (и деньги), чтобы найти, возможно, более оптимальную структуру.
М.
В моем магазине у нас есть что-то вроде этого:
RepositoryMain
Trunk
proj 1
proj 2
..
Dev
Team1
proj 1
proj 2
Team2
proj 1
proj 2
...
Я не знаю, как это складывается в большинстве мест, но кажется, что он работает очень хорошо.
Все команды разработчиков могут работать отдельно по своим проектам, слияния с магистрали и их проекта, когда они начинают разработку/расширение, а затем слияние с магистрали после их завершения.
Магистральные ветки и теги действуют одинаково. Как вы их используете, зависит от вас.
Я использую эту структуру в течение многих лет и еще не нашел время, когда структура не адаптировалась к тому, что мне нужно было сделать.
В таких системах, как CVS, вы не сохранили отдельные "каталоги". Вы просто отметились и разветвлены.
Однако SVN больше моделируется идеей моментальных снимков, и поэтому "копии" материала выполняются очень эффективно. Вместо того, чтобы отмечать или иным образом маркировать специальные (или альтернативные) версии проекта, проще (и более эффективно) сделать именованную копию.
Спасибо за обсуждение здесь, я прошел через это и project-structure-for-product-with-different-versions
Я мог видеть, что термины сбивают с толку. Проекты, Приложения, чтобы правильно соотнести
Хотел бы повторить вышеуказанные вещи с несколько ясными экс Допустим, мы делаем решение для клиента ABC Решение - это приложение TIcket/HelpDesk для запросов клиентов ABC.
Давайте скажем, что имя приложения - это OneDeskApplication. Это приложение состоит из из WebUI, общие библиотеки, средства сборки
мы можем спроектировать SVN, подобный этому
XSoftware.com/ABC - репозиторий / хобот / OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp ветки / Branch_Product_Support_1_0_0_0/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp теги / OneDeskDocs OneDeskMasterBuild