Итак, сразу опишу нашу ситуацию, а потом объясню, почему я дал этой статье такое дурацкое название :-) Наша команда из 4 человек работает над одним проектом (пока не скажу, что это за проект, надеюсь, напишу об этом позже) У нас было 3 ветки SVN: Production (стабильная ветка, обслуживающая запросы пользователей), Staging (промежуточная ветка), Trunk (ветвь разработчика).
В ходе итерации (мы работаем по Scrum, Скрам ), программисты фиксируются в одной ветке разработки (Trunk), после чего накопленные в ходе итерации изменения и возможности передаются в Staging ветку с помощью команды svn merge, где они тестируются и проверяются нашим QA. Далее, чтобы не делать очередной мерж в продакшене (из Staging в Stable) с последующим паническим тестом в продакшене после слияния.
Все, что я сделал, это изменил конфигурации на нашем веб-сервере.
$HTTP["host"] =~ "^.
*somehost.com$" { .
server.document-root = "/path/to/the/stable/branch" .
} $HTTP["host"] =~ "^.
*somehost.com.staging$" { .
server.document-root = "/path/to/the/staging/branch" .
}
После выпуска: $HTTP["host"] =~ "^.
*somehost.com$" { .
server.document-root = "/path/to/the/staging/branch" .
} $HTTP["host"] =~ "^.
*somehost.com.staging$" { .
server.document-root = "/path/to/the/stable/branch" .
}
Те.
в конце итерации Stable и Staging поменялись местами.
Стабильная версия стала невидимой для пользователей, а бывшая Staging стала рабочей, то есть туда, куда обращаются пользователи.
Вот мы и избавились от одного лишнего слияния.
Но этого нам показалось мало :-) Нет ничего более непредсказуемого, чем инженерия.
Мы решили удалить второй мердж, а точнее оставшийся.
Итак, условие задачи: у нас есть ветка разработки, в которой всегда содержатся самые последние изменения, и две ветки, каждая из которых поочередно выполняет роль производства.
Во время последнего слияния от разработки к стадии мы столкнулись с большими проблемами, из-за того, что все мы используем разные операционные системы (Arch linux, Mac OS, Windows Vista), разные IDE (Eclipse, Net Beans, Notepad++, VIM :-).
) ) И даже разные настройки внутри одних и тех же редакторов (сейчас я напишу спецификацию об общих настройках редактора).
В связи с этим для возврата каретки везде использовались разные последовательности символов, некоторые редакторы заменяли табуляцию пробелами и т. д. В связи с этим при слиянии у нас не возникло никаких конфликтов, SVN слил всё!!! По сути идентичные куски кода.
И мне приходилось проверять все вручную, чтобы привести сорта к желаемому виду.
Но в какой-то момент наши нервы не выдержали! И я просто удалил промежуточную ветку (svn delete staging), а затем мы просто скопировали текущую ветку разработки (транк) во вновь созданную (с помощью команды svn copy Trunk Staging).
Осталось только поправить конфиги во вновь созданной ветке и все.
Поэтому слияния как такового нет. В конце каждой итерации промежуточная ветвь удаляется (постановка svn delete).
И создается новый (постановка ствола копии svn).
И конфиги этому способствуют. Единственное, что меня беспокоило, это то, что размер репозитория будет быстро расти.
Но.
насколько я помню, SVN использует Пузыриться метод, в частности, для создания ветвей, поэтому вновь созданная ветка представляет собой просто ссылку на уже существующую базовую.
И изменения отличаются от этой базовой ветки.
Поэтому я совершенно спокоен относительно размера репозитория.
Я сейчас сижу и пишу эту статью, а QA тестирует наш проект на стадность :-))) Было бы интересно услышать ваше мнение об этом подходе.
З.
Ы.
На самом деле меня даже больше интересовали мнения по поводу мержа в Git Например, по словам Линуса Торвальдса: «Я знаю несколько компаний, которые используют git внутри компании, даже не подозревая об этом, потому что они по-прежнему хранят свои основные репозитории в Subversion, но многие разработчики затем импортируют код в git, потому что git действительно хорошо справляется со слияниями.
.
Таким образом, вы можете взять дерево ветвей из Subversion, импортировать его в git, позволить git выполнить слияние, что было бы большой головной болью в Subversion, зафиксировать изменения и фактически экспортировать их обратно в Subversion, и никто больше даже не узнает, что вы использовали мерзавец.
Это немного грустно, но я слышал о многих людях, работающих в компаниях именно по такому сценарию…» Git Google Talk Теги: #svn #svn merge #svn copy #svn delete #branches #Системы контроля версий
-
Оптические Инструменты
19 Oct, 24 -
Хабраfx Взлетает
19 Oct, 24 -
It-Мысли, Выпуск 6
19 Oct, 24
