SVN хорошая практика (филиалы)

Question

Наше приложение в настоящее время состоит из двух больших объектов: C# ASPX-файлов и файлов шаблонов отчетов RPT.

ASPX-файлы разработаны кем-то, а файлы RPT разрабатываются кем-то другим.

Оба мира не синхронизированы. Например, у вас может быть 10 новых версий для шаблонов RPT, а только один - в файле C#.

Есть ли способ разделить эти два логических потока части разработки одного и того же проекта в SVN? Должно ли все храниться в одном хранилище? Являются ли приложения SVN хорошим приложением для этого?

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

• /ModuleA/Main.aspx
• /ModuleB/Admin.aspx
• /ReportTemplates /Generic.rpt

Любые указания будут оценены!

Спасибо

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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