Разработка стратегии контроля версий для SVN

Вне часов я попытаюсь придумать стратегию контроля версий для моей компании; в настоящее время мы используем SVN, но у него нет структуры - у нас в основном есть только транк, и мы только фиксируем это. Недавно менеджер по разработке запустил второй репозиторий, который действует как наш «тег», но его необходимо вручную объединить с «стволом», поскольку он не является частью того же репозитория, а совершенно отдельным. По сути, есть только одна папка, которая называется «Dev» (на самом деле разные папки «Dev» в разные даты, но только «Dev» является основной), и под этим находится все остальное; все остальные проекты. Он вообще не организован проектом, у него нет понятия ветвей / тегов / ствола или чего-то еще. Человек, который установил это изначально (давно ушел, конечно), казалось, вообще не знал, как настроить SVN, и с тех пор никто не удосужился научиться делать что-то правильно, опасаясь что-то сломать. Мы не используем какие-либо CI (или, к сожалению, автоматическое тестирование).

Во-первых, мы должны отделить его от проекта? Например, у нас есть: два веб-сайта ASP.NET (не веб-приложения, веб-сайты), веб-служба, папка развертывания для всех табличных сценариев и хранимых процедур, два клиента командной строки для внешних проектов, которые вызываются Веб-сайты и общая папка, которая имеет общие бизнес-объекты и тому подобное. Должен ли каждый из них быть своим собственным проектом с настройкой branch / tag / trunk, или это должно быть так:

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

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

Во-вторых, мы делаем регулярные выпуски (на нашем языке «толкает») на наш сервер разработки и живой сервер. Из того, что я прочитал, лучший способ справиться с этим будет состоять в том, что вся разработка идет в ствол /, ветви являются «временными» и используются для добавления новой функции, которая может повлиять на ствол, а теги предназначены для релизов? Итак, каждый месяц мы работаем, скажем так, и я работаю над новым модулем. Я бы разветвлял магистраль и использовал эту ветку для своего кода, писал и тестировал его и все такое. Когда модуль будет готов, я сливаю его обратно в транк (и, возможно, удаляю ветку), и когда мы будем готовы к развертыванию, мы помечаем его (скажем, «May2011»). Если у нас есть исправление ошибки после его запуска, оно будет исправлено в теге May2011 и объединено с транком (так что транк также получит исправление), и тогда May2011 будет снова вытеснен с исправлением? Это намерение пометки?

Если вам нужен унифицированный процесс сборки, то обязательно поместите ветки / tags / trunk в корне, например так:

branches/
tags/
trunk/
  dev/
    ...

Если вам не нужен унифицированный процесс сборки, вы можете поместить ветки / теги / стволы в каждый проект, если хотите. Однако может быть трудно перейти на унифицированную сборку после помещения их в каждый проект. У объединенной сборки есть свои преимущества, такие как устранение необходимости публиковать общие компоненты между проектами - все они являются частью сборки.

Лично мне нравится единый процесс сборки. Кроме того, я не думаю, что у вас должен быть проект "dev". У вас должны быть проекты прямо под транком, а затем ветка транка в ветку dev. Используйте теги для релизов. Например, я бы сделал это так:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

1. Что касается структуры кода в SVN, то это действительно личный выбор.

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

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

1. Ваше описание использования тегов и ветвей звучит весьма разумно и именно так я и ожидал использовать svn. Это действительно намерение пометки, как я понимаю. Кстати, в SVN-тегах и ветвях фактически одно и то же, но терминология применяется так, как вы ее применили.

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

Следующее - лучший способ выложить репозиторий Subversion

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

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

Если вы хотите проверить все 3 проекта и выполнить унифицированную сборку с каким-либо монолитным сценарием / системой сборки, то попробуйте использовать мастер- модуль с помощью svn: externals, отображающего все остальные проекты в мастер trunk .

На первый взгляд, это сложнее, но это наиболее приемлемый и идиоматичный способ решения этой проблемы с Subversion.