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

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

Что касается ресурсов для CVS, см. главную страницу CVS.

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

Я бы рекомендовал прочитать две книги Pragmatic Programmer по SVN и CVS под названием "Прагматический контроль версий с использованием CVS" и "Прагматичный контроль версий с помощью Subversion ".

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

HTH

ваше здоровье,

Роб

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

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

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

Я считаю, что это от ужаса программирования:

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

Учебник по ветвлению и слиянию

Разумные практические правила:

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

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

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

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

Если вам нужен стартер на 10 для подрывной деятельности:

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

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

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

Создавайте определенные теги из веток вашей версии всякий раз, когда вы делаете сборку или исправление, которое будет выпущено для клиентов или развернуто в реальном времени. Назовите как "2.4.1", "2.4.2" и т. Д.

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

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

Прочтите это: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

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

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

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

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

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

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

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

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

Cederqvist обычно рассматривается как руководство по CVS.