Subversion объединяет изменения из другого репозитория

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

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

Я читал о ветвях поставщиков (http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html), но я не понимаю, почему слияние предыдущей копии кода поставщика и новая копия кода поставщика должна быть настолько сложной (т.е. svn_load_dirs.pl). Разумеется, если сторонний код хранится в репозитории SVN, вся история, в отношении которой были перемещены/удалены файлы, известна, почему вам нужно сообщить, что изменилось вручную?

Цитата:

Например, у вас будет возможность сообщить script, что вы знаете, что файл math.c в версии 1.0 libcomplex был переименован в arithmetic.c в libcomplex 1.1.

Я также прочитал (http://svn.haxx.se/users/archive-2006-04/0285.shtml), что можно просто запустить слияние между различными репозиториями, но я не сделал думаю, что это было возможно, и всякий раз, когда я это пробовал, он терпел неудачу (хотя я мог что-то делать не так).

Может ли кто-нибудь прояснить это для меня и предложить наилучшее решение?

Спасибо, Джек

Ответы

Ответ 1

Я только что попробовал короткий эксперимент с TortoiseSVN:

Создание тестовых репозиториев

  • создать два новых репозитория в rep1 и rep2
  • проверить rep1 в co1
  • добавить текстовый файл в co1 и проверить его в
  • экспорт rep1 в ex1
  • import ex1 в rep2

На этом этапе вы будете в состоянии создать свою локальную ветвь в новом репозитории. Последние два шага - все, что вам нужно для существующего проекта.

Чтобы имитировать некоторые изменения исходного репо, измените текстовый файл в co1 и зафиксируйте изменения.

Слияние изменений

Теперь, чтобы создать свою собственную рабочую копию, проверьте rep2 на co2.

Мы должны быть готовы попробовать слияние с rep1 в co2.

Откройте диалоговое окно слияния для co2 и наведите его на rep1.

В редакторе "from" выберите версию, в которой вы экспортировали свою копию (в данном случае ревизию 1), или версию, в которой вы в последний раз обновляли свою локальную копию.

Для пересмотра 'to' выберите HEAD или последнее обновление, которое вы хотите применить.

Результаты

Кажется, что это работает, как и ожидалось, с модификациями rep1, которые применяются к рабочей копии rep2 в co2. Затем они должны быть переданы обратно в локальный репозиторий.

Ответ 2

Связанная с вами ветвь поставщика позволяет эффективно описывать процесс того, что вы хотите сделать. Это идеальное решение, позволяющее вам выполнить прямое обновление (импорт) ветки поставщика, а затем, когда вы намекаете, позволит вам объединить обновления поставщиков с вашими изменениями в основной ветке разработки.

Проблема заключается в том, что Subversion действительно не обеспечивает прямую поддержку переименований файлов и перемещений файлов между каталогами для последовательного обновления из кода поставщика, потому что вы просто получаете моментальные копии содержимого исходных файлов.... что-то нужно для запуска команд в систему версий, чтобы указать, какие изменения вносятся в дерево имен файлов, которые составляют новую версию. Это цель процесса svn_load_dirs.pl script. Это поможет вам изменить историю версий, чтобы они соответствовали ветвям, чтобы затем вы могли продолжить слияние. Если поставщик не переименовал и не переместил файлы между импортированными вами версиями, у вас не возникло бы этой проблемы.

В любом случае описанный процесс - это то, что вам нужно сделать.

Ответ 3

Я не пробовал это с несколькими репозициями самостоятельно, но я не понимаю, почему вы не можете использовать предложения со своей второй ссылки.

svn merge ORIGINAL @REV UPGRADE @REV LOCAL_PATH

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

Protip: я всегда использую явные ревизии и включаю команду слияния с сообщением фиксации, чтобы я мог легко просматривать историю и понимать, как воспроизводить или отменять изменения.