Текущий / требуется в ветке поставщика?

Question

Что у меня есть

У меня есть база кода C ++, а * VCS svn *.

Мой код использует несколько сторонних продуктов. Мы используем разные версии каждого продукта и используем их в разных ОС (Linux и Windows).

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

Что я хочу

Я хочу изменить ситуацию. Идея состоит в том, чтобы использовать svn vendor branch . В отличие от того, что описано в ветке svn vendor , мы будем хранить двоичную версию стороннего продукта, а не сам код. Это потому, что мы никогда не исправляем сторонний код.

svn: external будет использоваться для использования соответствующей версии стороннего продукта. Вот скелет svn репозитория:

svn_repo/vendor/product1/OS1/ver1 <- mymodule using it
         vendor/product1/OS2/ver1 <- mymodule using it
         vendor/product1/OS1/ver2
         vendor/product1/OS1/ver2

         vendor/product2/OS1/ver1
         vendor/product2/OS2/ver1
         vendor/product2/OS1/ver2 <- mymodule using it
         vendor/product2/OS1/ver2 <- mymodule using it

         mymodule/   <- this is my actual code referring to a particular 
                        products from vendor/ using svn:external
         mymodule/vendor/product1/OS1   <- reference to vendor/product1/OS1/ver1
         mymodule/vendor/product1/OS2   <- reference to vendor/product1/OS2/ver1
         mymodule/vendor/product2/OS1   <- reference to vendor/product1/OS1/ver2
         mymodule/vendor/product3/OS2   <- reference to vendor/product1/OS2/ver2

Вопрос

В svn red book в главе ветка поставщика предлагается поддерживать текущую / содержащую последнюю версию стороннего продукта, поэтому из примера мы получаем:

   repos/vendor/libcomplex/current - contains 1.1
   repos/vendor/libcomplex/1.0
   repos/vendor/libcomplex/1.1 

Поскольку мы не исправляем сторонний код, я не вижу смысла поддерживать текущий /. Это выглядит так, чтобы поддерживать его, поэтому вы можете видеть, что svn поставляется с вспомогательным сценарием perl svn_load_dirs.pl , чтобы помочь.

Текущие предположения / необходимы для:

1. Чтобы сделать разные версии svn выпущенными и затем svn сопоставимыми.
2. Более того, версия более эффективно хранится в репозитории svn.

Я не вижу, что мы действительно нуждаемся в них.

Так что вопрос в том, сможем ли мы безопасно обойти обработку текущей / в ветке поставщика?

Answer 1

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

Вы даже можете рассмотреть возможность сохранения одной копии каждого двоичного файла для каждой операционной системы, т. Е. Забыли указать версию в имени каталога, просто используйте версию Subversion в качестве контроллера. Это делается с использованием явного номера ревизии в вашем свойстве svn: externals , что вам, вероятно, следует делать в любом случае.

Так что svn: externals на mymodule / vendor / product1 / OS1 будет установлен как -rXXX ^ / vendor / product1 / OS1 , где XXX - ревизия, содержащая соответствующую версию mymodule использует.

Например, в нашем каталоге инструментов есть двоичные файлы nunit. Если nunit выпускает новую версию, мы обновляем инструменты \ nunit и документируем в журнале сведения о выпуске. Все наши проекты, ссылающиеся на nunit, могут (необязательно) начать использовать новую версию, просто изменив номер ревизии свойства svn: externals для рассматриваемого проекта. Если какой-либо проект не хочет обновления, они ничего не делают:)

Answer 2

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

Answer 3

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

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

15.1.0.1901
-> update trunk
  -> copy trunk to new branches/15.1.0
  -> copy branches/15.1.0 to tags/15.1.0.1901
15.1.0.2233
-> update branches/15.1.0
  -> copy branches/15.1.0 to tags/15.1.0.2233
15.1.1.3064
-> update trunk
  -> copy trunk to new branches/15.1.1
  -> copy branches/15.1.1 to tags/15.1.1.3064
15.1.0.3299 (bug fix for 15.1.0)
-> update branches/15.1.0
  -> copy branches/15.1.0 to tags/15.1.0.3299

Код поставщика составляет около 180 МБ, в основном DLL-библиотеки .NET 3.5 с несколькими файлами PDB и XML. Я обнаружил, что экономия места была значительной, даже при коммите против транка, где я перешел с 15.1.0 на 15.1.1, где каждая DLL имела изменения.

Version     -> size of repos/db/revs file
15.1.0.2782 -> 19,076 KB
15.1.0.2845 ->     78 KB
15.1.0.2892 ->    130 KB
15.1.0.2907 ->    981 KB
15.1.0.2948 ->  1,021 KB
15.1.1.2998 ->  3,334 KB (new branch)
15.1.1.3064 ->    477 KB

Если предположить, что каждое обновление, зарегистрированное само по себе, занимало 19 МБ, я бы сейчас занимал около 133 МБ вместо 26 МБ, что экономило 80%. Теперь я не испытываю недостатка в дисковом пространстве, и Subversion определенно отлично справляется с компактным хранением, но я считаю это довольно неплохой экономией, которая стоит структуры и дополнительных операций копирования.

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

Answer 4

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

Поскольку вы имеете дело с двоичными файлами и вообще не исправляете их, вы можете игнорировать их.

Answer 5

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