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

Question

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

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

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

• / филиалы / разработка / FooModule?
• / development / FooModule?
• / песочница / modules / 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

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

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

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

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

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

Если у вас был хороший опыт работы с svn:externals, я - все уши.

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

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

Answer 5

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

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

Answer 6

Я не уверен, соответствует ли моя организационная структура вашим потребностям, но я использовал совершенно другой подход, чем модель 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 и каждая релиз имеет папку, названную в честь дата его выпуска. Постановка ветка копируется в эти версии теги при развертывании и они представить снимок кода в время выпуска. Площадь продукта историческая запись того, что именно был выпущен и когда.