Какова наилучшая практика при настройке подрывной деятельности для использования ветвей поставщиков? Наш репозиторий структурирован для отдельных проектов. Мы используем subversion 1.6.2 и tortoiseSVN 1.6.3.
Пример структуры папок:
Project1
/tags
/branches
/trunk
Project2
/tags
/branches
/trunk
В руководстве Subversion есть раздел, посвященный Филиалы поставщиков.
Основная идея заключается в том, что вы импортируете текущую версию без изменений в репозиторий через набор папок, отслеживающих внешние изменения (только внешние изменения, а не изменения). Что-то вроде ".../repos/vendor/(software)/current". Затем откройте сразу ".../repos/vendor/(программное обеспечение)/(версия программного обеспечения)". По мере появления новых выпусков обновите "текущий" каталог и создайте новую ветку, например ".../repos/vendor/(software)/(next-version)". Это позволяет вам (и svn) выполнять различия в немодифицированном источнике, чтобы получить то, что было изменено извне.
Для ваших изменений в программном обеспечении отнесите "(программную версию)" в свой собственный проект, что-то вроде ".../repos/(my-project)/trunk/(software)". Когда вы переходите к следующей версии стороннего источника, скажите svn объединить разницу между "(программной версией" "и" (следующей версией ") в рабочую копию" trunk/(software) ". Это вытаскивает все внешние изменения в багажник, аккуратно обновляя источник проекта. Разделите и пометьте проект как обычно.
В дистрибутив Subversion входит Perl script, называемый "svn_load_dirs.pl", который может помочь при обновлении проекта "поставщик". Он обнаруживает удаленные, добавленные и переименованные файлы и изменяет вашу рабочую копию, например "(текущий)", в зависимости от ситуации.
Для тех, кто приходит к этому позже, стоит знать, что с версии SVN 1.8 документированный метод обработки ветвей поставщиков, описанный в ответе Джеймса на этот вопрос, изменился.
На момент написания новой документации для этого все еще дорабатывается, чтобы увидеть, как он смотрит раздел "Отрасли поставщика" главы 4 книги SVN: http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html. Обратите внимание на предупреждения в верхней части этой страницы о том, что документация находится в процессе разработки.
То, что вы говорите, правда, но на практике вы увидите очень большую проблему.
Когда вы импортируете проект поставщика в ваш репозиторий subversion (и, предположим, проект поставщика - это большой, пусть говорят apache httpd 2.2), вы обнаружите, что невозможно импортировать свойства svn: ignore в каждом каталоге из-за факт отсутствия инструмента экспорта, который может сделать это только с доступом к интерфейсу WebDAV (есть инструмент svn admin, который может экспортировать svn-реквизиты, но требует прямого доступа к репозиторию поставщика).
Поэтому, когда вы импортируете проект поставщика, вам придется сначала экспортировать исходный файл из репозитория svn поставщика, а после импорта файлов в svn вы установите реквизиты svn вручную для каждого каталога внутри проекта. Очень краткий метод, но он единственный, если вы действительно хотите изменить проект поставщика и не отставать от своих изменений.