Лучшие практики Subversion

Когда мы говорим Subversion или SVN, каждый разработчик, который его использует, понимает, о чем мы будем говорить. SVN должен быть фактическим элементом любого цикла разработки. Мы можем использовать SVN не только с файлами кода, но и с любыми типами файлов, которые участвуют в процессе разработки (но это также не ограничивается этими файлами).

В этой статье мы рассмотрим, как мы можем эффективно использовать SVN, следуя нескольким практикам. Это поможет улучшить рабочий процесс разработки и сделать окончательный исходный код более стабильным. Когда мы говорим «стабильный», это означает, что у него будет меньше конфликтов, чем у других подходов, но сделать его на 100% бесконфликтным практически невозможно, потому что у всех разработчиков есть свои способы выполнения работы.

Мы рассмотрим следующие пункты в этой статье:

1. Шаблоны репозитория
2. Элементы репозитория
3. Отраслевая политика
4. Несколько важных практик

Шаблон репозитория

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

Один репозиторий

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

Есть разные способы, которыми люди следуют этому шаблону, ниже приведены некоторые из них:

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

Плюсы:

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

Минусы:

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

Шаблон с несколькими репозиториями

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

Плюсы:

• Мы можем определить права доступа для всех пользователей и проектов. Таким образом, у каждого пользователя будет доступ к проектам, в которых он участвует.
• Каждый проект будет иметь свою собственную последовательность номеров ревизий.

Минусы:

• SVN не поддерживается слиянием кода из другого репозитория.

Элементы репозитория

Репозиторий любого типа может содержать (но не ограничивается ими) три элемента: ветви, теги и ствол. Не существует такого четкого определения использования этих трех элементов. Мы можем выразить это любым способом, каким захотим. Хотите ли вы, чтобы теги были вашей основной линией разработки? Никаких проблем, просто продолжай и сделай это. Никто не арестует вас.

Но их маленькие рекомендации развивались на основе опыта работы с SVN, и у нас есть несколько рекомендаций по каждому из элементов.

Багажник

Магистраль используется для последней / текущей линии разработки.

ветви

Ветвь должна использоваться, когда у нас есть существенные изменения, которые могут прервать основную линию разработки (транк). Таким образом, чтобы работать без влияния на ствол, мы должны создать ветку из ствола и внести в нее необходимые изменения. Затем, когда мы закончим с изменениями, мы можем объединить эту ветку с транком.

Теги

Теги считаются снимком вашего кода в определенный момент, например, MileStone1, Milestone2 и т. Д.

Отраслевая политика

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

Никогда Ветвь

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

Плюсы:

• Очень простая политика
• Минимальная или нет кривой обучения. Разработчики должны пройти через процесс обучения ветвлению и слиянию.

Минусы:

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

Всегда филиал

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

Плюсы:

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

Минусы:

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

Филиал, когда это необходимо

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

Как определить эту потребность? В этом случае разработчик должен задать себе вопрос: а что, если мое изменение потребовало нескольких изменений? Если я собираюсь совершить все сразу, то это будет препятствовать или создаст проблему для рецензирования?

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

Плюсы:

• По сравнению с «Always Branch» этот метод имеет меньше разветвлений и слияний.
• Ствол гарантированно будет стабильным во все времена.

Минусы:

• Хотя это требует меньше ветвления и слияния, оно добавит дополнительные задачи для ветвления, слияния, компиляции и тестирования.

Важные советы

Используйте крючки

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

Будьте в курсе

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

Одна вещь за один раз

Представьте, что вы работали над несколькими изменениями, и вы фиксируете все файлы за один раз, говоря, что вы выполнили задание 1, задание 2 и задание 3. Через несколько дней какой-нибудь другой разработчик сможет определить, какие файлы связаны с какой задачей? Таким образом, существует очень простое правило: фиксировать одно изменение за раз, а не фиксировать несколько изменений в одном коммите.

Используйте сообщения журнала

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

1. «Завершенные изменения»: это неполно, и мы не можем понять, что было совершено.
2. «Завершена интеграция с Facebook, добавлены файлы Facebook SDK»: это полное и подробное описание. Он показывает, какие изменения были внесены и какие зависимые файлы были добавлены.

Совершать часто

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

Резервное хранилище

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

Вывод

Как упоминалось ранее в этой статье, в каменных правилах, определенных для использования SVN, нет никаких установленных. Поэтому я старался изо всех сил найти некоторые рекомендации по работе с SVN, основываясь на моем общем опыте.