svn: модульная организация на ранней стадии разработки

Question

Хорошо, я понимаю, что ствол / теги / ветки для репозитория с одним проектом.

Теперь предположим, что у меня есть основной проект и несколько небольших вспомогательных модулей / плагинов / инструментов / скриптов и т. Д. На ранних этапах происходит много переименований, реорганизаций и т. Д., И некоторые из них умирают рано, потому что уходят в никуда., Мне не имеет смысла вставлять конкретный модуль в магистраль, пока организация не станет достаточно стабильной. (в этот момент копирование в транк "дешево" в соответствии с дизайном SVN)

Где было бы лучше всего разместить небольшой модуль (скажем, "FooModule") в начале процесса разработки?

• / филиалы / разработка /FooModule?
• / разработка /FooModule?
• / песочница / модули /FooModule?

У кого-нибудь есть опыт организации хранилищ Subversion подобным образом? что сработало для вас?

Answer 1

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

1) положить все в багажник:

http://svn/application/trunk/application

2) если можете, начните рано разбивать код на модули

http://svn/application/trunk/application1
                             module1
                             module2

3) если модуль стабилен, переместите его вверх по течению в свой собственный репозиторий:

http://svn/module1/trunk

4) наконец, когда у вас есть несколько стабильных модулей и приложений, вы можете получить

http://svn/application1/trunk
http://svn/application2/trunk
http://svn/module1/trunk
http://svn/module2/trunk

каждое приложение / модуль имеет свой собственный цикл выпуска.

Кроме того, вы можете взглянуть на то, что делает Spring Framework (очень хорошая организация, если вы спросите меня)

http://svn/application1/trunk
http://svn/application2/trunk
http://svn/framework/trunk/module1
http://svn/framework/trunk/module2

Я бы посоветовал не разбивать код на транк / ветви для каждого модуля, по крайней мере, в начале проекта: как только вы начинаете ветвление (и не работаете на транке), вы не можете работать с ГОЛОВКАМИ транка других модулей. больше: вам нужно либо разветвлять все свои проекты одновременно, либо работать с конкретными версиями (1.0, а не SNAPSHOT). Я не думаю, что я очень ясно, но дайте мне знать, если я должен объяснить это по-другому.

Answer 2

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

Answer 3

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

app1/
    trunk/
    tags/
    branches/
app2/
    trunk/
    tags/
    branches/
sandbox/
    trunk/
    tags/
    sure_you_could_keep_the_parallelism_up_here_but_is_there_really_any_need/

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

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

Answer 4

Я не уверен, соответствует ли моя организационная структура вашим потребностям, но я использовал совсем другой подход, чем модель trunk/tags/branch. За подробностями обращайтесь на http://www.mattwrock.com/post/2009/10/10/The-Perfect-Build-Pard-2-Version-Control.aspx.

Вот наша структура:

/prod
/prod/app1/20090903
/prod/app1/20090917
/prod/app2/20090903
/sandbox
/sandbox/users/mwrock
/staging
/staging/app1
/staging/app2
/trunk
/trunk/libraries
/trunk/desktop
/trunk/docs
/trunk/services
/trunk/sql
/trunk/testing
/trunk/thirdparty
/trunk/web

Здесь у нас есть следующие корневые папки:

• Магистраль: содержит последние версии кода, подходящие для интеграции в магистраль. Существует один ствол, общий для всех проектов и команд. Разработчики должны только извлечь эту единственную папку, и у них есть все, что им нужно.

  Песочница: Это области личного развития, используемые для ветвления долгосрочных изменений, которые вы хотите хранить отдельно от ствола, пока они не будут готовы для объединения обратно в ствол.

  Постановка: это последняя область QA/UAT. Ствол копируется сюда, когда считается, что разработка стабильна и готова к финальному тестированию. Это защищает релиз от разработки, переданной в ствол другими командами. Когда релиз находится на этой стадии, вы не хотите, чтобы неизвестные коммиты от кого-то еще входили в вашу кодовую базу.

  Prod: Это содержит производственные выпуски. Каждое приложение имеет свою собственную папку в prod, и у каждого выпуска есть папка, названная в честь даты ее выпуска. Промежуточная ветвь копируется в эти теги выпуска при развертывании, и они представляют собой снимок кода на момент выпуска. Область Prod - это исторический отчет о том, что именно было выпущено и когда.

Answer 5

Я не могу редактировать пост Дэвида, но хочу кое-что упомянуть svn:externals: они довольно опасны с точки зрения выпуска (IMO). Вот сценарий кошмара:

Давайте представим, что вы svn:externals некоторый код модуля внутри вашего приложения; ради этого, давайте представим, что версия Subversion 1000 для модуля. Вы создаете филиал, делаете релиз и отправляете его клиенту.

Время идет, и через пару месяцев / лет клиент просит вас исправить проблему в приложении. Вы проверяете ветку и начинаете svn updating проект. К сожалению, связанный модуль сильно изменился и теперь имеет версию 23456. И теперь приложение даже не компилируется.

Конечно, что вы должны сделать, так что измените svm:externals указать точную версию (1000), когда вы разветвились. И если вам нужно изменить код модуля, то вам нужно указать сейчас на заголовок ветви, созданной для модуля в ревизии 1000.

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

Если у вас был хороший опыт работы с svn:externals Я весь внимание.

Answer 6

/branches/dev/FooModule было бы самым разумным подходом, если вы действительно не хотите иметь его в багажнике с самого начала ИМХО. Это то, для чего нужны ветки разработки (за исключением того, что обычно это происходит наоборот, код там копируется из транка, а затем в конечном итоге возвращается в транк).

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