Рекомендации CVS/SVN для разветвления и маркировки

Ответ 1

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

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

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

Ответ 2

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

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

НТН

веселит,

Rob

Ответ 3

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ветвление и слияние грунтовки

Ответ 6

Более поздние записи в Eric Sink Source Control HOWTO охватывают ветвление и слияние.

Ответ 7

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

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

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

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

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

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

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

Ответ 8

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

Ответ 9

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

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

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

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

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

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

Я бы рекомендовал использовать GIT, поскольку процесс tagging/branching чрезвычайно прост в использовании. Преимущество использования SVN (особенно в Windows) - это количество инструментов графического интерфейса пользователя и интерполяция оболочки Windows.

Я также закрепил рекомендацию для книг прагматического программиста по SVN.

Ответ 13

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

Существует довольно простое объяснение, чтобы вы начали здесь.