Subversion Vendor Филиалы - PullRequest
Новая
       35

Subversion Vendor Филиалы

10 голосов
/ 22 июня 2009

Какова оптимальная практика при настройке Subversion для использования веток поставщиков? Наш репозиторий структурирован для индивидуальных проектов. Мы используем Subversion 1.6.2 и tortoiseSVN 1.6.3.

Пример структуры папок: 

Project1
 /tags
 /branches
 /trunk

Project2
 /tags
 /branches
 /trunk
  1. Где бы я мог поместить папку vendors и какую структуру она должна иметь?
  2. Есть ли пример использования клиента tortoisesvn?

Ответы [ 3 ]

13 голосов
/ 22 июня 2009

В руководстве Subversion есть раздел, посвященный Ветвям поставщика .

Основная идея заключается в том, что вы импортируете текущую версию без изменений в хранилище через набор папок, которые отслеживают внешние изменения (только внешние изменения, а не ваши изменения в нем). Что-то вроде "... / repos / vendor / (software) / current". Затем сразу перейдите в "... / repos / vendor / (software) / (software-version)". По мере выхода новых версий обновите «текущий» каталог и создайте новую ветку, например «... / repos / vendor / (software) / (next-version)». Это позволяет вам (и svn) делать различия на неизмененном источнике, чтобы получить то, что изменилось извне.

Для ваших модификаций программного обеспечения, добавьте "(версия программного обеспечения)" в ваш собственный проект, что-то вроде "... / repos / (my-project) / trunk / (software)". При обновлении до следующей версии стороннего источника скажите svn объединить разницу между «(версия программного обеспечения)» и «(следующая версия)» в рабочую копию «ствола / (программное обеспечение)». Это вытягивает все внешние изменения в магистраль, аккуратно обновляя исходный код проекта. Разветвите и пометьте проект как обычно.

В дистрибутив Subversion входит Perl-скрипт с именем «svn_load_dirs.pl», который может помочь при обновлении проекта «vendor». Он обнаруживает удаленные, добавленные и переименованные файлы и изменяет вашу рабочую копию, например, «(текущая)», в зависимости от ситуации.

3 голосов
/ 15 ноября 2013

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

На момент написания новой документации для этого все еще дорабатывали, чтобы увидеть, как это выглядит в разделе Ветви поставщика в главе 4 Книги SVN: http://svnbook.red -bean.com / nightly / en / svn.advanced.vendorbr.html . Обратите внимание на предупреждения в верхней части этой страницы, касающиеся документации, находящейся в стадии разработки.

0 голосов
/ 19 января 2010

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

Когда вы импортируете проект вендора в свой репозиторий subversion (и предлагаете проект вендора, это большой проект, скажем, как apache httpd 2.2), вы обнаружите, что невозможно импортировать свойства svn: ignore в каждый каталог из-за тот факт, что не существует какого-либо инструмента экспорта, который мог бы делать это только с доступом к интерфейсу WebDAV (есть инструмент администратора SVN, который может экспортировать реквизиты SVN, но требует прямого доступа к хранилищу поставщика).

Таким образом, когда вы импортируете проект вендора, вам сначала нужно будет экспортировать исходный из репозитория svn vendor, а после импорта файлов в svn вы установите svn props вручную для каждого каталога внутри проекта. Очень удобный метод, но он единственный, если вы действительно хотите изменить проект вендора и идти в ногу с его изменениями.

...