Лучшие практики SVN - работа в команде

Question

Я начинаю с SVN. Я знаю основные команды и понимаю основные принципы. Мне было интересно, есть ли у кого-нибудь какие-либо советы или рекомендации по работе с Subversion в командной среде.

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

Спасибо за отличные ответы - они очень помогли.

Answer 1

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

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

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

Answer 2

Не фиксировать изменения форматирования при изменении кода

Если вы хотите реструктурировать пробелы в гигантском файле ( Control + K + D ), хорошо. Зафиксируйте изменение форматирования отдельно от фактического логического изменения. То же самое происходит, если вы хотите перемещать функции в файлах. Зафиксируйте перемещение отдельно от фактического редактирования.

Answer 3

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

Answer 4

Много уже было упомянуто, а вот еще несколько:

1. Если у вас есть файлы, которые вам не нужны в управлении исходным кодом (например, конфигурация, скомпилированные файлы и т. Д.), Добавьте их в список ignore . Таким образом, вы замечаете любые файлы, которые вы забыли добавить, всегда ожидая пустой список файлов, отображаемых как неизвестные для SVN.

2. Добавьте событие post commit, которое отправит электронное письмо в список рассылки вашего разработчика (или сообщение, специфичное для этой цели), касающееся зафиксированного изменения и в идеале патч для него.

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

4. Рассмотрите возможность интеграции с непрерывной интеграцией (например, CruiseControl.NET ), NAnt для Build и NUnit / VS для юнит-тестов. Таким образом, как только пользователь регистрирует код или по расписанию, код компилируется, запускаются модульные тесты, и разработчик получает обратную связь с процессом. Это также предупредит остальную часть команды, если хранилище будет повреждено (т.е. не будет построено).

Answer 5

Ну, азы:

• Создание тегов перед запуском QA для версии
• Создание тегов перед рискованными изменениями (т.е. большими рефакторами)
• Создание веток для выпущенных версий, чтобы заморозить код.
• Убедитесь, что люди знают, что нужно обновить, прежде чем начинать работу над куском кода, и обновите еще раз, прежде чем его фиксировать.
• SVN допускает несколько проверок одного и того же файла разными пользователями. Убедитесь, что каждый разрешает любой конфликт, который может возникнуть.
• Никогда не может использовать одну и ту же учетную запись SVN для более чем одного пользователя. Могут возникнуть ужасные вещи.

Answer 6

Ответы, которые дают люди, великолепны. Многое из этого обобщено в документации пользователя svn для рекомендаций для SVN .
Повторить:

1. Настройте структуру своего хранилища (у вас должен быть корень проекта с транком, ветвями и тегами внизу)
2. Выберите свою политику повторного перехода (частные филиалы, количество веток на этап / выпуск / ошибка, и т.д.) и придерживайтесь этого - я бы рекомендую больше ветвлений, чем меньше, но не нужно для частного ветви
3. Выберите ваш полис теги - чем больше тегов, тем лучше, но самое главное определиться с вашим тегом соглашения об именах
4. Выберите свой политика повторного совершения в багажник - держите багажник как можно более чистым, он должен быть доступен для любого время

Answer 7

Я хотел бы обобщить лучшие практики, которые я придерживаюсь:

1. Не фиксировать двоичные файлы . Должен быть отдельный репозиторий для двоичных файлов, таких как Nexus , Ivy или Artifactory .

2. Должна быть структура хранилища . Лично я использую следующую структуру хранилища:

   /trunk
   /tags
       /builds
           /PA
           /A
           /B
       /releases
           /AR
           /BR
           /RC
           /ST
   /branches
       /experimental
       /maintenance
           /versions
           /platforms
       /releases
   

3. Использовать определенный список типов ветвей . Мой список следующий: экспериментальный , обслуживание , версии , платформы , релизы .
4. Используйте определенные типы тегов : PA (пре-альфа), A (альфа), B (бета), AR (альфа-релиз), BR (бета-релиз), RC (релиз-кандидат), ST (стабильный).
5. Минимизировать необходимость слияния . Должны быть правила, когда слияние возможно / поощряется, а когда нет.
6. Нумерация версий . Должен быть установлен подход к нумерации версий. Обычно это описывается в таком документе, как План управления конфигурацией программного обеспечения, является частью высокоуровневой проектной документации. Лично я использую сложный подход к нумерации версий. Согласно этому подходу версии имеют следующие шаблоны: Nxx (ветки обслуживания / поддержки), NMx (ветка выпуска), NxK (сборка), NMK (выпуск).
7. Фиксация как можно чаще . Если это трудно (например, когда нужно внести слишком много изменений для реализации функции и даже для компиляции кода), следует использовать экспериментальные ветви.
8. Багажник должен содержать последнюю разработку . Например, когда есть выбор, где разрабатывать новую основную версию ( Nxx ) приложения, в trunk или в филиале, решение всегда должно быть принято в пользу trunk . Старая версия должна быть разветвлена ​​в ветку maintenance / support . Предполагается, что существует четкое различие между основными версиями и их специфика (архитектура, совместимость) появляется как можно раньше .
9. Строгая политика "не нарушать сборку" в ветвях выпуска . Между тем, оно не обязательно должно быть строгим для trunk , если оно может иметь либо экспериментальную разработку, либо базу кода, которая требует решения проблем слияния для решения.
10. Использование svn: externals . Это позволит модулировать ваш проект, установить прозрачную процедуру управления релизами, разделять и завоевывать различные функции.
11. Использовать отслеживание проблем . Вы сможете указать ссылку на проблему в сообщении о фиксации.
12. Отключить пустые сообщения о фиксации . Это можно сделать с помощью хуков предварительной фиксации.
13. Определите , какие ветви вы хотите непрерывно интегрировать . Например, я предпочитаю использовать непрерывную интеграцию для транка , обслуживания и выпуска ответвлений.
14. Установить Политика непрерывной интеграции для разных типов филиалов. Как я указывал ранее, самые строгие правила «не нарушать сборку» применяются к ветвям release , тогда как ветви trunk и maintenance иногда могут быть повреждены. Также существует разница между списком проверок, выполняемых в ветвях магистраль / обслуживание и выпуск .

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

Answer 8

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

1. Если у вас есть отдельные репозитории для кода различных модулей / библиотек и ссылки на те, которые вы используете. Это означает, что вы можете иметь мета-репозиторий для каждого исполняемого файла. Если это небольшой исполняемый файл, который использует только несколько модулей, вам не нужно извлекать все дерево. В результате вы получаете номера ревизий SVN для каждого модуля.
2. Добавление больших двоичных данных, таких как скомпилированные версии библиотек, в репозиторий кода обычно считается плохой привычкой, но это может быть очень удобно. Если вы просто добавите все версии всех библиотек, которые вы используете, в другое хранилище, вы сможете получить лучшее из двух миров. Вы ссылаетесь в версиях библиотек, которые вы используете в вашем хранилище кода. При проверке вашего хранилища кода вы получите и код, и двоичные файлы. Однако двоичные файлы хранятся в большом репозитории, резервное копирование которого вам не требуется, так как ваш исходный код и репозиторий исходного кода остаются маленькими и содержат только текст.

Answer 9

Используйте интеграцию с вашей программой отслеживания ошибок. Если вы используете Bugzilla , вы можете настроить его так, чтобы, если ваш комментарий начинается с «Ошибка XXXX», ваш комментарий SVN автоматически добавляется как комментарий к данной ошибке, включая ссылку на ваш веб-интерфейс SVN с этим пересмотр.

Answer 10

Узнайте об инструментах и ​​соглашениях SVN для ветвления и слияния.

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

Таким образом, люди могут работать для достижения общей цели (либо в одной ветви, либо в отдельной ветви), не сталкиваясь с другими изменениями.

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