svn поддерево, обновление из одного репозитория, принятие в другое

Question

svn поддерево, обновление из одного репозитория, принятие в другое

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

Как я могу "экспортировать" одну папку / модуль моего репозитория, чтобы я мог оформить заказ только этого модуля в другой проект? Мои другие проекты, в которые я хочу включить этот модуль, также находятся в их собственном репозитории SVN.

В резюме я хотел бы иметь возможность делать SVN-обновление основного репо, но делать коммиты репо проекта.

Я надеюсь, что ясно, что я хочу сделать.

В ответ на DavidW ответ:

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

4

svn svn-externals subtree svn-export

Источник

user407468 11 апр '13 в 11:58

2 ответа

Решение

Если вы хотите использовать общий код внутри хранилища Subversion - это svn:externals
Если вы хотите изменить порт из основной линии общего кода в специфическую для клиента версию общего кода - это svn lingo - "ветви поставщика".

Совокупность а) и б) даст вам необходимый результат

Выберите какой-либо узел (вне ствола хранилища клиента), который вы будете связывать с общим узлом в dev-repo
Создайте внешнее определение (с предпочтением PEG-ревизии, если вам нужно будет легко рассчитать время, затрачиваемое на ручное обновление определений после фиксации в dev-repo)
Скопировать узел в то место, где должен быть живой проект (svn cp ...)
Код...
Если у вас есть изменения в dev-repo, которые вы хотите перенести в репо клиента - обновите внешние компоненты до необходимой ревизии, объедините узел "Vendor" в "Live"

Образец:

Если вы будете в репо клиента

/vendor/lib (где lib - это каталог из внешнего репо) */trunk/common/lib (версия lib клиента выше)

изменения из lib-mainline - это слияние с / vendor / lib в / trunk / common / lib (в соответствующем узле рабочей копии для вашей магистрали)

Примечания Дэвида о внешнем мире все еще актуальны, правильны и полезны

1

Источник

user960558 11 апр '13 в 20:12

Другие вопросы по тегам svn svn-externals subtree svn-export

user368630 11 апр '13 в 13:34 2013-04-11 13:34 · Accepted Answer · 2013-04-11 13:34

Несколько вопросов:

Вы говорите о нескольких репозиториях или о нескольких проектах в одном репозитории?
Если вы заимствуете код этого другого модуля, синхронизируете ли вы его с этим другим модулем или разветвляете этот модуль?
Что вы действительно хотите поделиться? Вы должны поделиться исходным кодом или скомпилированным выводом (*.so или же *.a в Unix C/C+, *.jar на Яве и т. д.).

Ответ, который вы дадите, во многом зависит от ваших ответов на эти вопросы.

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

В этом случае используйте svn:externals, Это свойство, которое вы помещаете в каталог. Он связывает URL-адрес Subversion с именем подкаталога. Например:

$ svn propset svn:externals "http://svn.vegibanc.com/svn/trunk/project/stuff utils" .

Поместим свойство в текущий каталог. Когда вы делаете обновление или извлечение, каталог называется utils будет создан в вашем проекте, и Subversion автоматически оформит заказ http://svn.vegibanc.com/svn/trunk/project/stuff в этот каталог. Это магия, но, как и всякая магия, она имеет как светлую, так и темную сторону.

Прежде всего светлая сторона:

Это общий код между двумя проектами. Вы вносите изменения в свой utils и внесите изменения, а stuff подкаталог в project будет обновлено. Я использую его для встраивания инструментов в мои проекты. Если я обновлю инструмент, все проекты получат обновленные инструменты.

Теперь темная сторона:

Если вы определите svn:externals Точно так же, как я показал вам, вы будете глубоко сожалеть об этом. Представьте, решите ли вы опубликовать свою работу для выпуска. Ну твой utils каталог по-прежнему указывает на trunk из project/stuff, Если вы переходите на выпуск 2.1, а транк теперь работает на 2.2, вы собираетесь получить материал в utils что ты не хочешь.

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

Поэтому настоятельно рекомендуется указывать точную версию URL:

$ svn propset svn:externals "-r23283 ^/trunk/project/stuff@23283 utils" .
$ svn propset svn:externals "^/tags/2.3.3/project/stuff utils" .

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

Второй указывает на конкретный тег. Это не так безопасно, так как теги могут быть изменены, но я могу трактовать свою внешнюю зависимость как релиз. Я использую релиз 2.3.3 утилиты вещи.

Оба используют ^ ярлык, который просто означает Корень хранилища Subversion. Таким образом, если вы переместите свой репозиторий Subversion в другую систему или измените http в svnТвои внешние функции все еще будут работать. Конечно, если вы сделаете это таким образом, вы никогда не сможете изменить код в svn:externals, И это не то, что вы хотите.

Вы также можете использовать относительные URL, но они немного опаснее.

Представьте себе два ваших проекта, и вы хотите сделать каталог вещи svn:external ссылка на каталог утилит:

http://svn.vegibanc.com/svn/trunk/project/foo/stuff
http://svn.vegibanc.com/svn/trunk/project/bar/utils

Проект разветвляется и помечается вместе. Вы могли бы сделать это:

$ co http://svn.vegibanc.com/svn/trunk/project/bar bar-trunk
$ cd project-bar
$ svn propset svn:externals "../foo/stuff utils" .

Это внешне свяжет каталог вещи с вашим каталогом утилит. Тем не менее, это сделано в относительной манере. Если вы делаете это:

$ cp http://svn.vegibanc.com/svn/trunk http://svn.vegibank.com/svn/branches/2.3

Ваш каталог утилит по- прежнему будет внешне связан с каталогом вещи в проекте foo, но оба они будут в ветке 2.3.

Изменение кода в bar/utils изменит код в foo/stuff и наоборот. Вы по-прежнему делитесь кодом, но таким образом оба проекта находятся в одной ветке.

Позже, если вы отметите это так:

$ cp http://svn.vegibank.com/svn/branches/2.3 http://svn.vegibank.com/svn/tags/2.3.0

Ваш тег 2.3.0 вряд ли изменится, потому что внешние ссылки и ссылки, на которые они ссылаются, заключены в этот тег.

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

Лучший способ сделать это для foo создать какой-то скомпилированный объект (например, файл JAR или *.so), который можно сохранить на сервере релизов. Вы рассматриваете этот скомпилированный объект как свой собственный проект с его собственной версионностью, и ваш проект будет зависеть от конкретной версии этого объекта. К сожалению, это не всегда работает.

Если вы просто разветвляете код, сделайте svn cp с одного места в хранилище на другое. Вы можете внести свои изменения, не затрагивая другой проект и наоборот. Более того, вы можете объединять изменения назад и вперед между двумя местоположениями, чтобы поддерживать их синхронизацию.

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