Вы используете соглашение веток / тегов / транка?

Question

Всегда ли вы придерживаетесь соглашения о размещении веток, тегов и директорий транков на верхнем уровне вашего хранилища Subversion? В последнее время я перестал беспокоиться, и ничего плохого не произошло (пока)!

Должна быть возможность перемещать деревья каталогов, если возникнет необходимость их создания. Я создаю проблемы на потом?

Answer 1

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

Answer 2

Быстрый ответ: «делай все, что подходит для твоих процедур».

Как сказал Данимал, структура branch / trunk / tag является соглашением. Однако я не согласен с тем, что важно расположение б / т / т, а просто их наличие.

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

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

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

Answer 3

В прошлом я писал инструменты для автоматизации определенных частей SVN. Создание базового хранилища является одним из них. Шаг 1: создайте пустой репозиторий. Шаг 2: создать ствол, ветки и папки с тегами - зафиксировать Шаг 3: Скопировать подключаемые скрипты в новый репозиторий

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

Answer 4

Я только начал фактически использовать соглашение, и я согласен с Danimal . Если у вас есть одна сборка в QA, другая в Production и другая в разработке новых сумасшедших экспериментов, неплохо бы быстро переключаться между ними.

Answer 5

Это зависит от того, насколько велик проект. У нас есть кое-что (да, в git, но концепция та же), которая довольно большая. Каждый разработчик использует свою собственную ветку, есть ветка тестирования и магистрали. Мы также помечаем выпуски, и, если есть исправления для конкретной версии, создается ветка, так что исправления могут быть легко интегрированы.

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

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

Answer 6

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

Если, с другой стороны, вы управляете кодом, развернутым на 700 разных сайтах и ​​разбитым на отдельные продуктовые линейки, вам будет безумно не использовать «ветвь, тег, ствол» в верхней части вашей структуры (есть разумное основание для разделения ваших продуктов перед переходом по BTT-маршруту), поскольку вам нужно будет знать, куда и куда пошел код, и уметь разделять основные действия по перезаписи (то, что вы делаете в ствол) из точечных исправлений, чтобы помочь сайту, имеющему непосредственную проблему (что вы делаете в ветке, затем сливаетесь в ствол). И если вы хотите иметь возможность ответить на вопрос «Почему Foobar перестал работать, когда мы выпустили патч 1.2.3?» тогда теги необходимы.

Answer 7

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

Answer 8

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

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

Answer 9

Я придерживаюсь соглашения по многочисленным причинам

1. Справочные материалы и процедуры, в которых используется соглашение b / t / t, могут быть немедленно применены к вашей структуре репозитория SVN.
2. Все разработчики, входящие в команду, знакомые с соглашением, имеют минимальную кривую обучения, чтобы привыкнуть к вашей структуре репозитория SVN.
3. Если стволы и ответвления имеют непосредственное и очевидное преимущество, то только тогда, когда вам приходится перелистывать истории и журналы, чтобы охватить вашу задницу или вашу компанию, вы понимаете преимущество поддержания последовательной процедуры тегирования.

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

Answer 10

В последнее время я использую модель, более ориентированную на Agile, и вы можете посмотреть здесь .

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

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