Subversion, версия с тегами, общие библиотеки

Question

Моя команда собирается выпустить релиз, и мы хотим пометить релиз в Subversion.Релиз (v.1) состоит из нескольких приложений, и все они ссылаются на общие библиотеки.Я читал, что наиболее часто используемый способ организации ствола / ответвлений / тегов - это делать для каждого проекта.

Вопрос № 1: Так что, чтобы сделать релиз с этой структурой, мне придется каждый раз отмечать тегамипроект отдельно?Я думаю, что могу создать несколько уровней ствола / веток / тегов, по одному в корне и по одному для каждого проекта.Это позволило бы мне создать тег для всего моего кода из корневого ствола.

would look something like this:
/rep
    /trunk
        /office
            /project1
                /trunk
                /branches
                /tags
            /project2
                /trunk
                /branches
                /tags
        /shared
            /shared_project
                /trunk
                /branches
                /tags
    /tags
    /branches

Вопрос № 2: Если мое решение для Q # 1 - плохая идея, и я должен пометить каждый проект для себяЧто тогда, если мы позже обнаружим ошибку в v.1 и должны сделать исправление.Должен ли я снова вручную переключать каждый проект на тег v.1 и переходить каждый из них в ветку разработки?

Редактировать

Спасибо за ваши ответы,Я решил, что я собираюсь убедить мою команду перейти на Mercurial, похоже, это правильная VCS для того, как мы хотим работать.Я также посмотрел на Git, но HQ выглядит более гладким.

Answer 1

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

Если вас беспокоит усилие, необходимое для тегирования всех этих проектов, вы можете легко сделать это с помощью клиента командной строки svn

svn cp <branch> <tag> -m"tagging release v.1"

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

Пример

Предположим, что ваш репозиторий расположен на http://mysvn/ и имеет следующую структуру:

/rep
  /trunk
        /project1
        /project2
        /shared_project
  /tags
  /branches

Если вы хотите пометить проекты из транка, вы можете запустить следующие команды из командной строки.

svn cp "http://mysvn/trunk/project1" "http://mysvn/tags/project1 v.1" -m"tagging release v.1" 
svn cp "http://mysvn/trunk/project2" "http://mysvn/tags/project2 v.1" -m"tagging release v.1" 
svn cp "http://mysvn/trunk/shared_project" "http://mysvn/tags/shared_project v.1" -m"tagging release v.1" 

Результатом является следующий макет хранилища

/rep
  /trunk
        /project1
        /project2
        /shared_project
  /tags
        /project1 v.1
        /project2 v.1
        /shared_project v.1
  /branches

Другой подход предполагает, что ваш репозиторий имеет следующую компоновку:

/rep
  /project1
     /trunk
     /tags
     /branches
  /project2
     /trunk
     /tags
     /branches
  /shared_project
     /trunk
     /tags
     /branches

В этом случае вы будете помечать следующие команды:

svn cp "http://mysvn/project1/trunk/" "http://mysvn/project1/tags/v.1" -m"tagging release v.1" 
svn cp "http://mysvn/project2/trunk/" "http://mysvn/project2/tags/v.1" -m"tagging release v.1" 
svn cp "http://mysvn/shared_project/trunk/" "http://mysvn/shared_project/tags/v.1" -m"tagging release v.1" 

Это переведет ваш репозиторий в следующее состояние:

/rep
  /project1
     /trunk
     /tags
       /v.1
     /branches
  /project2
     /trunk
     /tags
        /v.1
     /branches
  /shared_project
     /trunk
     /tags
        /v.1
     /branches

Лично я предпочитаю первый подход, так как он держит папки под тегами на том же уровне, что и в транке, и вы не получите кучу папок с именем "v.1". В конце концов, это вопрос предпочтений.

Answer 2

Мне эта структура кажется неправильной:

/rep
    /trunk
        /office
            /project1
                /trunk

Почему есть trunk ниже /rep? Должно быть:

/rep
    /office
        /project1
            /trunk

Далее необходимо создать тег, содержащий все версии в определенное время. Я предлагаю создать ueberproject, который содержит другие проекты, такие как /rep/all/tag/1.0/office/project1

Заполните ueberproject с помощью svn copy или с помощью svn:external.

Первый использует SVN как версионную файловую систему: вы создаете копии файлов, над которыми хотите работать.

Последний создает легкие ссылки на фрагменты, которые вам нужны. В SVN обе операции стоят примерно одинаково (svn copy также создает внутреннюю пару ссылок; фактически ничего не копирует!)

Исправление ошибок

Если вы обнаружите ошибку в v1, вы должны экспортировать проект в DCVS, например, Mercurial или Git, создать там ветки и исправить ошибку.

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

См. http://hginit.com/ для более подробного объяснения, почему вы не хотите начинать с веток в Subversion.

Если вы все еще хотите попробовать, прочитайте и поймите это: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html

Answer 3

вот мое мнение по вашим вопросам.

Q1: Вы можете использовать один репозиторий для всех своих проектов, как и вы.Вы можете сделать моментальные снимки (теги) каждого проекта перед его развертыванием на производственном сервере, например, версия проекта тега1 в trunk / office / project1 / tags

Однако, для меня более правильно эта структура:

/rep
   /trunk
     /project1
     /project2
     /shared
   /tags/
     /project1
     /project2
     /shared
   /branches
     /project1
     /project2
     /shared

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

Q2.Если вы обнаружите ошибку в теге v1, вам нужно переключиться с этого тега в ветви или исправить ошибку в стволе и выполнить новое развертывание на рабочем сервере плюс новый тег - это зависит от вашего цикла разработки.

Answer 4

Прежде всего позвольте мне сказать, что здесь нет правильного ответа (хотя есть много неправильных).

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

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

Для общих библиотек выследует использовать внешние SVN - хранить общие библиотеки в отдельной сборке и использовать внешние для включения их в сборку.

 /rep
     /trunk
           /office
                  /project1
                  /project2
                  /project3

         /Release 1.0
           /office
                  /project1
                  /project2
                  /project3
         /Release 1.1
           /office
                  /project1
                  /project2
                  /project3
        /Release 2.0
           /office
                  /project1
                  /project2
                  /project3
     /tags
        /Release 1.0
           /office
                  /project1
                  /project2
                  /project3
        /Release 1.1
           /office
                  /project1
                  /project2
                  /project3
        /Release 2.0
           /office
                  /project1
                  /project2
                  /project3

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

Так что в ответ на 2) да, если у вас есть ошибка в Release2.0, которая была развернута 2 недели назад, вам нужно переключиться на работу в ветке R2.0, исправить ошибку, а затем объединить исправление с магистральной связью, чтобы она также была включена в будущие выпуски.

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