Лучшая практика для объединения / не объединения тегов SVN
Я создал тег с именем v1.5 с ветки. После некоторого тестирования я обнаружил некоторые ошибки, и мне кажется, что я должен распространить эти изменения на tag/v1.5, Но я вижу некоторые комментарии, которые не предлагают такую практику обновления или объединения тегов.
Мой вопрос - как лучше всего справляться с такими ситуациями? Возможно удалить тег и воссоздать его из ревизии главы филиала?
3 ответа
Теги, ветки и т. Д. Не имеют никакого смысла для самой Subversion, они просто папки и вы можете делать все, что захотите. Тем не менее, существуют хорошие практики, и теги означают то, что вы никогда не измените. Вы должны иметь рабочий процесс и придерживаться этого.
Например, мы делаем новые разработки в багажнике. Когда все будет готово, мы создаем ветку, например, 1.5, а затем создаем теги, например, 1.5.1, 1.5.2, 1.5.3 и т. Д. Мы добавляем исправления ошибок и создаем из них новые теги, но не добавляем новые функции. на ветви, и мы никогда не меняем теги. Затем мы объединяем исправления из ветки в ствол, когда появляются новые разработки. Это очень распространенный рабочий процесс.
Вот более длинная статья, то, что я описал выше, называется "моделью стабильного выпуска", здесь есть хорошее изображение, чтобы показать вам, что и где происходит. Есть также альтернативы и долгая дискуссия. Мне нравятся эти графики, вот еще один, но он немного запутанный, стрелки не должны пересекать теги, теги всегда должны быть тупиком.
Лучшая практика не удалять tags на самом деле теги не предназначены для прикосновения, это всего лишь метки, в то время как в любом хранилище SVN все является папкой, практика обычно заключается в том, чтобы работать над trunk, Обновить branches в случае ошибок, и оставить tags В качестве маркеров для предыдущей истории работы для справки, ветви также могут использоваться для отдельной работы, лучше всего работать с одним магистральным шаблоном одной магистрали и максимально избегать ветвей (непрерывная интеграция доставки), но в вашем случае я бы ответвление от tag и обновление его, а затем объединение обратно в транк. tags предназначены, чтобы остаться. что я хотел бы сделать, это скопировать tag в branch с именем филиала и сделайте обновление там. тогда я бы merge это назад к trunk, для автоматических слияний есть крутая утилита для svn под названием automerger утилита
Google и Facebook приняли разработку на основе транков. разработка В вышеприведенных материалах эти гуглеры говорили о работе над HEAD и о том, что проверки происходят с HEAD всегда. Ашиш говорит о транке несколько раз ближе к концу в разделе вопросов и ответов, и он упоминает об избежании ветвления для текущей разработки (ничего общего с выпусками как таковыми). Таким образом, Google официально занимается разработкой магистральных систем (TBD), и они делают это! ( http://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/)
Теги в SVN - это (условно) поддерево RO. Если вы изменили после создания кода тега, вы должны создать новый тег из измененного кода