Subversion объединяет изменения из другого хранилища

Question

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

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

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

Цитата:

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

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

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

Answer 1

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

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

1. создайте два новых репозитория в rep1 и rep2
2. проверить rep1 в co1
3. добавить текстовый файл в co1 и проверить его в
4. экспорт rep1 в ex1
5. импорт ex1 в rep2

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

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

Объединение изменений

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

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

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

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

Для ревизии 'to' выберите ГОЛОВКУ или последнее обновление, которое вы хотите применить.

Результаты

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

Answer 2

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

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

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

Answer 3

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

svn merge ORIGINAL @ REV UPGRADE @ REV LOCAL_PATH

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

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