Лучшие практики CVS / SVN для ветвления и тегирования

Question

Я буду нести ответственность за принятие решения о том, как будут происходить разметки в нашем репозитории CVS / SVN.

Есть ли литература, которая поможет мне понять, как лучше всего работать с CVS? либо ветвление / маркировка, и т. д.?

спасибо

Answer 1

Мой личный опыт более чем 10-летнего опыта работы с CVS в проекте FreeBSD: переключайтесь на что-то еще как можно быстрее. CVS ориентирован на файл, а не на снимок / набор изменений, что делает объединение ветвей довольно болезненным. В любом случае с CVS ветки болезненны.

Что касается ресурсов для CVS, см. CVS Home

Если вы хотите поговорить о SVN, я бы предложил SVN Book и сам этот вопрос .

Answer 2

Я бы рекомендовал прочитать две книги Pragmatic Programmer по SVN и CVS, которые называются « Прагматическое управление версиями с использованием CVS » и « Прагматическое управление версиями с использованием Subversion ».

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

НТН

ура

Rob

Answer 3

Я полагаю, это от ужаса кодирования:

Статья Криса Бирмела о ветвлении и слиянии - лучшее введение, которое я нашел в этой важной задаче контроля исходного кода. Есть десятки способов ветвления, и нет единственно правильного способа сделать это. Познакомьтесь с вашими вариантами, чтобы вы знали, каковы компромиссы с каждым.

Учебник для ветвления и слияния

Answer 4

Я рекомендую вам SVN в Windows, Git в Linux. Не используйте CVS, имхо, это ужасно.

Книга SVN - это то, что вам нужно в первую очередь.

Пометить каждую публичную сборку (релиз). По какой-то причине ветвь является копирующим стволом - например, другой путь развития. Филиал репозитория каждый раз, когда вам нужно:)

Answer 5

Толковые правила:

• Пометить каждую сборку (т. Е. Каждую сборку номером сборки - все, что вы можете отправить тестерам или кому-либо еще).
• Разветвляйте каждый раз, когда вам нужно разветвляться.

Обычно вам нужно ветвить выпущенные версии, чтобы вы могли тестировать и выпускать патчи. У вас могут быть другие причины для ветвления.

И вам определенно лучше с Subversion.

Answer 6

Читать это: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Answer 7

Если вы хотите стартер на 10 для subversion:

Рассматривайте «ствол» как полную историю вашего развития. Все, что когда-либо освобождается, должно появиться в багажнике в какой-то момент и в некоторой форме.

Использование веток разработки (веток от ствола) в сложных задачах разработки. Когда задача завершена, используйте re-интегрировать слияние, чтобы перенести изменения из ветви в ствол. Таким образом, у вас есть несколько конкретных коммитов на транк вместо множества коммитов, связанных с одной и той же задачей. Удалите эти ветки разработки, когда они больше не нужны. Назовите их как «FeatureX»

Использование веток версий (снова из транка) для управления маркетинговыми версиями, которые предназначены для выпуска клиентам / развертывания в режиме реального времени. Версия - это подмножество ревизий в транке. Чтобы их использовать, выполните ветвление из ствола с соответствующей ревизией (может быть, не с заголовком), вручную запишите ревизии из ствола как слитые с этой веткой, объедините любые дополнительные ревизии, которые вам нужны, из ствола (только из ствола). Не разрабатывайте непосредственно в ветви версии, только объединяйте из транка - хотя объединение может потребовать дополнительной работы, чтобы сделать его совместимым с версией. Название как 'Версия 2.4'

Создавайте определенные теги из ветвей вашей версии всякий раз, когда вы делаете сборку или исправление, которые выпускаются для клиентов или развертываются в live. Название как «2.4.1», «2.4.2» и т. Д.

Работая таким образом, вы можете использовать отслеживание слияний в Subversion (версия 1.5 и выше), чтобы точно видеть, что находится в каждом теге в редакции по редакции. Для этого получите рабочую копию вашего тега или ветки версии и выполните команду 'svn mergeinfo --show-revs merged http://svn/trunk c: \ workingcopy \'

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

Answer 8

Более поздние записи в Source Control HOWTO Эрика Синка охватывают ветвление и слияние.

Answer 9

Когда я пришел к своему первому настоящему SCM (из безопасного источника) несколько лет назад, я нашел следующее полезное - тогда, по-моему, был официальный документ по производительности:

http://www.perforce.com/perforce/bestpractices.html

Answer 10

Вы должны оставить CVS. CVS старый и не очень быстрый с точки зрения ветвления / тегирования (создание веток / тегов линейно зависит от количества файлов в проекте)

Сначала вы должны подумать о стратегии ветвления : хотите ли вы иметь

• стабильный багажник
• функциональные ветви
• ветки разработчика
• нестабильный ствол / выпуск ветвей
• ветки платформы

Это сильно зависит от вашего проекта и философии разработки

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

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