Структура хранилища SVN - Почему это лучше?

Я сказал, что большинство магазинов развития имеют следующую структуру или, по крайней мере, близко к этому:Структура хранилища SVN - Почему это лучше?

Главная Repository
- папки проекта находящиеся под
- Каждая папка проекта имеет ствол, ветви, и теги папку

так:

ReponsitoryMain 
    Project1 
     branches 
     trunk 
     tags 
    Project2 
     ...

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

источник

2009-07-31 PositiveGuy

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

Вы говорите «лучше», но лучше, чем что? –

Спасибо всем! Очень ценится. – PositiveGuy

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

ReponsitoryMain 
    Project1 
     branches 
     trunk 
     tags 
    Project2 
    ...

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

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

источник

2009-07-31 18:34:19

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

М.

источник

2009-07-31 18:16:06 Max

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

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

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

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

источник

2009-07-31 18:16:38

хорошая ссылка, спасибо большое. Это также очень полезно. – PositiveGuy

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

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

источник

2009-07-31 18:18:33 pgb

Зачем вы хотите его заархивировать? Это команда Subversion? – PositiveGuy

просто для экономии места и храните его в надежном месте, а не каждый день. – pgb

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

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

источник

2009-07-31 18:28:49 Gren

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

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

или что-нибудь другое, что имеет смысл процесс.

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

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

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

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

источник

2009-07-31 18:32:22

, когда вы не поддерживаете общие ресурсы. В моем первом примере, что, если есть проект 3, который использует Project 1 и Project 2, означает, что Project 3 имеет только одно решение. – PositiveGuy

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

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

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

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

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

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

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

источник

2009-08-06 16:50:45

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

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

источник

2009-08-06 17:08:56

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

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

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

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

источник

2009-08-06 17:16:45 Stevus

Это интересная идея; это почти как система управления распределенными источниками. –

Спасибо за обсуждение здесь, я прошел через этот и project-structure-for-product-with-different-versions

link2

link3

link4

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

Хотел бы повторить вышеуказанные вещи с несколько ясно ехр Допустим, мы делаем решение для клиента ABC Solution является билет/HelpDesk приложений для клиентов АВС Запросы

Допустим, applicationName - это OneDeskApplication. Это приложение состоит из WebUI, разделяемых библиотек, Build Tools

мы можем спроектировать SVN как этот

XSoftware.com/ABC - Repository / багажник/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp ветви/ Branch_Product_Support_1_0_0_0/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp теги/ OneDeskDocs OneDeskMasterBuild

источник

2012-07-05 02:31:27 user1502707

У вас, кажется, есть хороший контент здесь, но это немного беспорядок. – thecoshman

Структура хранилища SVN - Почему это лучше?

ответ

Смежные вопросы