У меня в настоящее время есть проблема, на которую я не смог найти ответ, поскольку это кажется немного особенным.SVN: копирование из одного хранилища в другой, сохранение внешних
Моя проблема:
У нас есть два хранилища здесь. Репозиторий A содержит общие вещи, а репозиторий B - это один конкретный проект.
В репозитории У нас есть проект-шаблон, который сам включает внешние элементы из репозитория A. Теперь мы хотели бы скопировать этот проект шаблона в репозиторий B, чтобы запустить конкретный проект на основе шаблона. Но мы хотели бы сохранить внешние шаблоны, ссылающиеся на источники в репозитории A. Они были установлены с относительными путями (^/.. /, поскольку оба хранилища имеют один и тот же базовый URL-адрес), поэтому он должен работать.
При создании шаблона мы думали просто создать его ветку и начать разработку на этом рабочем примере. Но, как оказалось, создание ветки не является вариантом при пересечении границ репозитория.
То, что я пытался
(я использую Tortoise SVN)
СВН скопировать из хранилища A в репозитарий B, чтобы создать что-то вроде филиала. Это несчастливо не работает, поскольку svn-копия не может использоваться в разных хранилищах.
Экспортируйте шаблон из репозитория A и включите его в репозиторий B. Таким образом, я получаю текущую версию внешних, но это уже не свойство svn. У экспортированной версии больше нет svn-информации, так как она должна работать?
Vendorbranch: Это приводит к аналогичному результату с экспортной версией. Внешнее свойство исчезло.
Мой вопрос
Как я могу получить шаблон из репозитория А в хранилище B, но сохранить внешнеположенности как собственность, не сбрасывая их вручную?
Или еще один шаг назад: вы видите другое решение по созданию рабочего шаблона проекта программного обеспечения, которое может быть использовано позже в других репозиториях?
Спасибо за ваш ответ. Не могли бы вы объяснить, почему относительные пути - плохая идея? Я имею в виду, что это официально упоминается в книге svn, и это позволяет избежать проблем при изменении базового URL-адреса. Я могу попробовать попробовать svnrdump.Мне нужны права администратора для репозитория? – Gunter
@Gunter - I * предположим *, с внешними добавленными вами «общий контент», который вы хотите увидеть и использовать централизованно (возможно, в URL-адресе A) для любых дочерних проектов во всех репозиториях (которые или совместно используют общий сервер или нет). Относящиеся к репо внешние ресурсы не позволят вам иметь такую централизацию –
Вы правы, хранилище A хранит централизованный «общий контент». Все репозитории для дочерних проектов расположены на одном сервере и будут доступны для следующего будущего. Так что для нынешней ситуации это работает. Для меня это решает проблему, когда все репозитории перемещаются в другое место. Что мне кажется более вероятным, чем разделение репозиториев на разные серверы. Когда репозитории перемещаются на разные URL-адреса, конечно, нам придется переключиться на абсолютные URL-адреса для внешних. – Gunter