Прочтите раздел Ветви поставщика Красной книги Subversion ( Контроль версий с Subversion ):
http://svnbook.red -bean.com / о / 1,5 / svn.advanced.vendorbr.html
Общая процедура управления филиалом поставщика
Управление ветвями поставщиков обычно работает следующим образом: сначала вы создаете каталог верхнего уровня (например, / vendor) для хранения веток поставщиков. Затем вы импортируете сторонний код в подкаталог этого каталога верхнего уровня. Затем вы копируете этот подкаталог в свою основную ветку разработки (например, / trunk) в соответствующем месте. Вы всегда вносите свои локальные изменения в основную ветку разработки. С каждым новым выпуском кода, который вы отслеживаете, вы переносите его в ветку поставщика и объединяете изменения в / trunk, разрешая любые конфликты, возникающие между локальными изменениями и исходными изменениями. ... (См. Остальную часть главы Ветви поставщика в главе для конкретных команд и полного примера.)
Обычно вы проверяете код поставщика отдельно от вашего проекта, отмечаете версию и затем svn копируете ее в ваш проект. Это позволит вам вносить локальные изменения, сохраняя при этом указатель на исходную версию выпуска.
Преимущество состоит в том, что когда поставщик выпускает новую версию своего продукта, в руководстве описывается, как включить новую версию в ваш проект, чтобы те же локальные изменения, которые вы внесли в исходную версию, применяются к новой версии. , Это, конечно, звучит в теории, но на практике может быть несколько ошибок:
Но все не всегда так просто, и на самом деле исходные файлы часто перемещаются между выпусками программного обеспечения. Это усложняет процесс обеспечения того, что наши модификации все еще действительны для новой версии кода, и вещи могут быстро ухудшиться в ситуации, когда нам придется заново создавать наши настройки в новой версии.