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

9

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

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

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

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

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

Уэйн Молина
источник
5
Нестандартная стратегия: переключитесь на git.
Рейн Хенрикс
Если бы это был вариант, я бы сделал это (или Mercurial, так как мы магазин Windows). Я думаю, что столкнулся бы с еще большим сопротивлением, пытаясь перейти на совершенно новую систему контроля версий, чем пытаться, по крайней мере, создать надлежащую среду с SVN.
Уэйн Молина
2
Хотя я взволнован DVCS, Subversion - хороший инструмент. CVS или другое решение без управления версиями папок было бы хуже.
Мэтью Родатус
2
@ Уэйн М - Вы можете обнаружить, что на самом деле все наоборот. Возможно, будет проще заставить людей подписаться на более разумную структуру среды, если они получат все преимущества использования DVCS. В качестве перехода вы можете подумать о том, чтобы заставить peopel попробовать дешевый локальный доступ к ветвлению / репо с помощью gitsvn или hgsubversion. После того, как они подключены и привыкли к инструментам, вполне может появиться желание всей группы перейти на DVCS для первичного репо.
Марк Бут

Ответы:

5

Если вам нужен унифицированный процесс сборки, то обязательно поместите ветки / 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
У объединенной сборки есть свои преимущества, такие как устранение необходимости публиковать общие компоненты между проектами - все они являются частью сборки.
Мэтью Родатус
2
Если вам нужно несколько унифицированных сборок, создайте для каждой директории под стволом. Но я бы не назвал одного «dev» - это лучше сделать с помощью ветки. Например, у вас может быть две основные организации разработчиков: одна работает с драйверами устройств, а другая - с веб-сайта компании. Возможно, вы захотите две отдельные унифицированные сборки.
Мэтью Родат
1
  1. Что касается структуры кода в SVN, то это действительно личный выбор.

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

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

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

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

Люк Грэм
источник
Вы говорите, что только проверенный, готовый к работе код должен быть в транке? Я думаю, что любой код, который передается, должен создавать и, вероятно, проходить тесты, а транковый код, конечно, должен проходить тесты. Но кажется, что цель SVN - следить за историей разработки, и это проще, если она не разбита на несколько ветвей. Возможно, должна быть ветвь, в которую вы объединяете магистраль, когда магистраль находится в проверенном, готовом к работе состоянии?
Мистер Джефферсон
0

Следующее - лучший способ выложить репозиторий 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.


источник
2
Я категорически не согласен. Хранилище делает больше, чем просто хранит код; он передает организационную структуру и отношения между компонентами; это жизненно важный, хотя и неявный канал связи. Если вы разбиваете каждый проект отдельно, вы вводите искусственные и ненужные барьеры для общения.
Уильям Пейн