Подтвердить что ты не робот

Соглашение об именах SVN: репозиторий, ветки, теги

Просто интересно, что означают ваши соглашения об именах:

Название хранилища ветки Теги

В настоящее время мы используем следующие стандарты с SVN, но хотели бы улучшить его:

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

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

Итак, если ваш проект похож на Backyard Baseball for Youngins, как вы справляетесь с этим?

  • backyardBaseballForYoungins
  • backyard_baseball_for_youngins
  • BackyardBaseballForYoungins
  • backyardbaseballforyoungins

Это кажется довольно тривиальным, но это вопрос.

Если вы идете с парадигмой ветки функций, как вы называете свои ветки функций? После самой функции на простом английском языке? Какая-то схема управления версиями? То есть скажем, вы хотите добавить функциональность в приложение Backyard Baseball, которое позволяет пользователям добавлять свою собственную статистику. Что бы вы назвали своей веткой?

  • {repoName}/ветвь/пользователь-ADD-статистика
  • {repoName}/ветки/userAddStatistics
  • {repoName}/ветки/user_add_statistics

и др.

Или:

  • {repoName}/branches/1.1.0.1

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

  • {repoName}/branches/1.1.0.1 - добавить статистику пользователя
  • {repoName}/branches/1.1.0.2 - admin добавить статистику

И как только они будут объединены в багажник, соединительная линия может увеличиваться соответственно?

Теги

Кажется, что они больше всего выиграют от номеров версий.

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

Но, какова ваша политика SVN в будущем?

4b9b3361

ОТВЕТЫ

Ответ 1

Я использую ствол, теги, модели ветвей.

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

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

теги: предназначены для выпусков или стабильных версий кода, на которые я хочу быстро вернуться. Обычно я использую их для конкретной версии (1.00) модуля или приложения. Я стараюсь не делать никаких проверок для тегов. Если есть ошибки, то эти изменения производятся в багажнике и будут доступны для следующей версии. Единственные исключения, которые я делаю, - это аварийные ошибки. Это означает, что тег будет правильно QA'd и достаточно стабилен.

Ответ 2

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

  • trunk - не используется, чтобы избежать путаницы
  • ветки - ветки релиза, одна релизная жизнь - около года, названная сокращенным названием продукта и текущим годом (LDN_FSHCHPS_REL_2010)
  • теги - неизменяемые метки релиза/патча (сделанные с помощью svn copy), автоматически генерируемые из метки времени (LBL_20100526180134 = 2010-05-26 18:01:34), выпуски версий генерируются с той же отметки времени, что и v10.05.26. 180134, поэтому легко сопоставить ярлык с версией
  • рабочие области - особенности/отдельные ветки разработчиков, растут из веток /LDN _FSHCHPS_REL_2010 для новой разработки или из тегов /LBL _20100526180134 для исправления, ветвление выполняется с помощью svn copy, backmerge - с svn merge, переключение выполняется с помощью svn merge --reintegrate, рабочие пространства называются так же, как WS_, где автоматически генерируется script (автоинкрементный)

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

Ветвление/слияние разрешено только для каталогов второго уровня и только полные слияния, а не отдельные файлы /dirs (например, ветки /LDN _FSHCHPS_REL_2010 → workspaces/WS_345), чтобы включить автоматическое слияние и избежать проблем с информацией об объединении поддеревьев (и также для облегчения rootcausing проблем слияния, когда они происходят)

Ответ 3

CamelCase? Нет, мы не вводим никаких ограничений на имена, за исключением того, что пространства, как правило, не поощряются. Содержание - это то, что важно, а не презентация. Пока имя четко определено, что он делает, мы счастливы.

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

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

например:

base v1
  +--- moduleA
  +----moduleB
base v2
  +--- moduleA
  +----moduleB

Мы думали о размещении ветки тегов под каждым из каталогов модулей, но мы почти всегда имеем дело с головной версией, поэтому это не проблема для нас. Мы регулярно объединяем изменения от старых базовых модулей версии к новому - например, внесите изменения в moduleA для базы v1, изменения будут объединены в базовый модуль v2. Мы не возвращаемся назад, если это необходимо.

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

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

Да, мы вносим изменения в багажник, но это нормально с нашим документооборотом - вещи не срабатывают, пока они не готовы. Все изменения, внесенные в старые версии, являются исправлениями ошибок, и у нас слишком много модулей для управления ими в полном цикле dev-test-release. Мы исправим, если это окажется плохим решением, мы снова исправим. Мы иногда меняем этот подход для более крупных разработок и создаем ветку в папке веток (от корня). Путь ветки снова создает путь к исходному модулю (поэтому его легко определить, что это такое, и слияние обратно так же просто, как изменение/ветки в /trunk в начале пути).

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

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

Ответ 4

В настоящее время мы используем следующие стандарты с SVN...

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

Итак, если ваш проект похож на Backyard Baseball for Youngins, как вы справляетесь с этим?

Мы - магазин Java, поэтому все наши проекты называются gov.bop.project.:-) Subversion работает с любыми именами.

Если вы идете с парадигмой ветки функции, как вы называете ветки вашей функции?

Мы идем с номером, сгенерированным нашей системой отчетов об инцидентах. Это повышает надежность.

Теги

Кажется, что они больше всего выиграют от номеров версий.

Мы обнаружили, что даты yyyymmdd работают лучше в течение длительного периода времени.