Стандартные практики для Subversion

Question

Мне интересно, есть ли другие факторы, которые следует учитывать для стандартной практики использования Subversion.

Несколько у меня есть:

• Структура каталогов /tags /trunk и /branch

• Вся работа выполняется в багажнике, который не нарушает функциональность

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

• Теги содержат стабильные релизы

• Всегда выполняйте обновление перед началом работы

• Внесите изменения в конце дня / когда функция была добавлена

• Примечания фиксации содержат соответствующее описание

• Фиксация, основанная на функции - не закрывайте коммит

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

Я буду признателен вашему критику за любые мои идеи и любые ваши идеи, которые я пропустил.

Спасибо!

Answer 1

Еще несколько заметок:(постарался не повторять то, что уже было сказано..)

Ветви:

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

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

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

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

Подтверждает:

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

2. Я голосую за частые коммиты, если не каждый день. Это мышление. Как только вы увидите преимущества ранних коммитов (разумеется, после того, как разработчики проверит основные ошибки компиляции и запустят модульные тесты в своем наборе разработчиков), вы будете рады обнаружить эти ранние ошибки / проблемы сборки. Если вы планируете запускать ночные сборки или использовать инструмент непрерывной интеграции, вам лучше заставить людей принять обязательства как можно раньше, чтобы получить представление об интегрированных потоках работы и провести на них тесты.

Метки:

1. Прибавьте соглашения об именах релизов - хотя это кажется тривиальным, это помогает иметь хорошие имена тегов. Также убедитесь, что комментарии фиксации для тегов точно указывают, почему вы помечаете эту версию репозитория. Мы помечаем теги только тогда, когда мы выполняем промежуточные сборки, поэтому в нашем случае мы сопоставляем сообщения фиксации тега с непрерывным номером сборки (тегом сборки круиза), который мы используем для данной сборки. Также полезно иметь схему нумерации выпусков и определенные поля, чтобы вы могли использовать их для тегов.

Answer 2

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

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

Answer 3

Если вы новичок в SVN, то хорошим (бесплатным) ресурсом является книга SVN (копии "мертвого дерева" также можно приобрести у O'Reilly).

Answer 4

Если для выполнения "функции" потребуется более нескольких (4–6) часов, я бы

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

Answer 5

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

TDD очень помогает в этом отношении.

Answer 6

"Однако фиксация только после того, как функции были завершены, может быть вызвана устаревшими / конфликтами?"

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

Answer 7

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

Зафиксируйте атомарный набор связанных изменений. Не делайте большой коммит с несвязанными изменениями во всем. Это значительно упрощает отслеживание конкретных изменений.

Вы можете иметь несколько проверок одного и того же источника - полезно, если вы экспериментируете с несвязанными изменениями.

Избегайте фиксации неработающего кода или кода с ошибочными тестами или с другими нерешенными проблемами.

Answer 8

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

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

Этот подход ветвь - объединить... объединить - объединить назад - удалить работает хорошо для нас

Answer 9

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

Хорошая книга по шаблонам SCM / стандартным процедурам, которая мне показалась полезной, - "Шаблоны управления конфигурацией программного обеспечения: эффективная командная работа, практическая интеграция от Berczuk и Appleton".