SVN маркировка файла готовой продукции

Question

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

Сейчас я работаю над большим проектом с несколькими разработчиками, и мы ищем лучший процесс развертывания. Одна вещь, на которой мы зациклены, - это лучший способ пометки, ветвления и так далее. Мы привыкли к CVS, где все, что вам нужно сделать, это зафиксировать файл и пометить его как готовый к работе, а в противном случае этот код не будет развернут.

Я вижу, что SVN обрабатывает теги не так, как CVS. Я полагаю, что я смотрю на это и делаю это слишком сложным. Кажется, что единственный способ работать над проектом и фиксировать файлы без его нахождения в рабочем коде - это сделать это в ветке и затем объединить эти изменения, когда вы будете готовы к его развертыванию. Я предполагаю, что вы могли бы также работать над другим кодом, который должен быть развернут, чтобы вам приходилось переключаться между рабочими копиями, потому что в противном случае вы работаете над веткой, которая не смешивается с внешней или рабочей веткой?

Этот процесс кажется слишком сложным, и мне было интересно, кто-нибудь может дать мне то, что, по вашему мнению, является лучшим процессом для управления этим.

Answer 1

Существует две школы для работы с SVN (и большинством других централизованных VCS):

1. Stable Trunk - транк, где находится весь ваш хороший стабильный код. В багажник вносятся только безопасные изменения «одного рабочего узла». Все ваши разработки делаются в ветвях, а затем объединяются в ствол. Когда наступает время релиза, вы помечаете из ствола.

2. Нестабильный ствол - ствол - ваш «кровоточащий край». Все новые вещи попадают в багажник. Когда ваша работа начинает превращаться в релиз, вы создаете ветку, где вы можете работать над стабилизацией и полировкой всего. В итоге вы получите ветку для каждого выпуска (ветки / v1.0, ветки / v1.1 и т. Д.). Вы отмечаете из ветки релиза, когда она готова.

Примечания о модели № 1:

• Люди могут работать в филиалах, не топая друг на друга.
• Вы можете разделить нестабильную разработку по своему усмотрению, даже одну ветвь на разработчика.
• Вы можете иметь иерархические ветви с качественными воротами между ними. Пример: Джо передает нестабильную информацию в свою частную ветвь, когда Джо доволен своей работой, она объединяется с ветвью на уровне команды, которая проверяется более формально, а затем объединяется в магистраль с полностью проверенной работой другие команды.
• Это означает много слияния в обоих направлениях. Материал толкают до сундука. Изменения в магистрали должны распространяться вниз по ветвям.
• До появления функций отслеживания слияний в SVN это было действительно сложно.

Примечания к модели № 2:

• Разработка более совместная. Это отговаривает людей работать слишком долго в изоляции, а затем сбрасывать бомбу на кодовую базу.
• Будет много неработающих сборок, если вы не навязываете какую-то дисциплину с помощью тестирования перед фиксацией.
• Это поощряет сохранение модульной базы кода, поэтому у вас не будет всех, кто борется за одновременное изменение одних и тех же файлов в транке.
• Эта модель упрощает управление обновлениями более старых и новых версий (например, вы выпускаете исправления как для v1.x, так и для v2.x).
• Для длительных изменений вам, возможно, понадобится ветвь, чтобы все равно работать с этой функцией.

Я видел, как обе модели работают очень хорошо. Это зависит от того, как работает команда и как строится кодовая база.

Answer 2

мы делаем следующее и очень довольны:

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

У меня есть папка проектов, в которую я извлекаю ствол, последние несколько веток релиза и ветвь функций, над которыми я сейчас работаю. таким образом я могу легко фиксировать и объединять различные ветви.

еще два полезных правила:

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

Answer 3

Какой лучший процесс зависит от ряда факторов. Насколько велики ваши изменения, какие они (исправления ошибок, новые функции), сколько у вас разработчиков?

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

Но главное беспокойство, которое у вас, похоже, может быть решено, на самом деле с помощью двух стволов. Один для текущей версии разработки / тестирования и один для текущей стабильной версии. Затем вы можете объединить изменения из разработки в стабильную перед их развертыванием. В конце концов, это более или менее похоже на другую ветку, общую для всех разработчиков.

К счастью, Subversion позволяет вам делать все это без проблем.

Лучшим источником дополнительной информации может быть SVN Book

Answer 4

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

Абсолютно верно. Это способ работы с SVN, TFS и большинством современных систем управления исходным кодом.

Обычный рабочий процесс состоит в том, чтобы иметь ветку TRUNK, максимально приближенную к производственной, и ветку Main, над которой выполняется работа - для больших функций вы создаете подветви из своей ветви.

Существуют распределенные SCM, такие как Git и Mercurial, которые не работают таким образом, но есть вероятность, что вы найдете их еще более сложными, чем SVN.

См. это сообщение в блоге об одной стратегии ветвления (стратегия ветвления SVN, которая работает).

Здесь - другое (Простое ветвление и слияние с SVN).