Объединение изменений из одного хранилища во многие другие

Question

Я собираюсь дать некоторую информацию, чтобы вы могли понять, где я нахожусь с этим, так что потерпите меня:

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

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

Более того, мой босс, хочет разделить все разные клиенты на разные репозитории (которыея мог бы сказать, что это логично), но поскольку у меня не может быть одной основной копии каталога, он становится адом, когда мне нужно объединить изменения из основного репозитория с разными клиентами.Простое изменение в 1-10 строк можно выполнить в 9 каталогах, но сегодня мне поручено добавить в него целую функцию обработчика платежей, и она дает мне около 700 строк в 35 файлах для изменения ...

Я пытался в течение часа искать, как объединить или воспроизвести изменения из моей основной ветки @ rev54 в любой другой репозиторий @rev ???но все, что я получаю, - это очень долгое время ожидания и сообщения о конфликтах, или у меня возникают проблемы с сообщением «X не в репозитории Y».

Вот что я попробовал:

Поиск: Svn mergeизменения в разных репозиториях Поиск: Svn-воспроизведение изменений в другом репозитории Поиск: Svn-слияние изменений в репозитории

Чтение бесчисленных сообщений в StackOverflow

Чтение бесчисленных сообщений в блоге

Пытался: cd client1 /кошка/;svn merge --dry-run http://svnserver/svn/mainbranch/trunk@54 Пробовал: cd client1 / cat /;svn merge --dry-run http://svnserver/svn/mainbranch/trunk@54 http://svnserver/svn/clientbranch/trunk@5.

Посмотрел также документацию по "расширенному слиянию" из svn redbook, похоже, ничто не дает простых результатов "воспроизведения".

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

Answer 1

Хорошо, в конце концов, это казалось сложнее, чем было на самом деле, я смог сделать это простым:

CD "directory you merge into"
svn merge -r"lastrev":HEAD <URL TO THE PATH TO MERGE>

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

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

Надеюсь, это поможет кому-то позже

Answer 2

Не то, что вы хотите услышать, но этот тип сценария будет проще с Git или HG.

В git вы говорите о центральном репо, из которого могут объединяться все клиентские репо ипросто имейте это как дополнительный пульт, который они иногда извлекали бы / тянули.Или же вы можете использовать команду cherry pick, чтобы довольно легко перемещать изменения из одного репо в другое.

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

edit: В зависимости от того, что такое «ядро», вы можете использовать внешние SVN, чтобы все файлы ядра были в одном репозитории.Но это удалит для каждого клиента изменения в ядре.

Answer 3

• Экспорт отдельного коммита в виде патча
• Применить исправление к клент-коду (разрешить конфликты)

Слияние репозиториев (ключевое слово для поиска было слияние svn репозиториев ) дает такие ссылки

1. Как объединить два репозитория SVN
2. Слияние репозиториев SVN

Answer 4

У вас может быть один репозиторий, содержащий все клиенты.

Например:

/core/trunk/....
/client_a/trunk/...

Возможно, стоит иметь ветку vendor для каждого клиента:

/client_a/vendor/...

Ветвь поставщика в client_a будет /core/trunk (или /core/branches/etc) с момента последнего слияния. Обычно можно использовать ветку вендора для отслеживания изменений из репозитория верхнего уровня, когда вы затем вносите свои собственные изменения. Это позволяет позже объединять изменения без конфликтов из верхнего хранилища в ветку поставщика. Попав в ветку вендора, вы можете легко отличить текущую версию вендора от предыдущей, чтобы рассчитать, какие изменения необходимо внести.

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

---

Если вы не можете создать один репозиторий, то вышеупомянутое применимо. Снова относитесь к «ядру» как к восходящей ветке поставщиков. При извлечении изменений в клиентский репозиторий извлеките ветку поставщика этого клиента и замените весь контент, который там находится в данный момент, последней копией из ядра, а затем подтвердите. После этого вы можете объединить различные значения между vendor@head и vendor@prev в транк этого клиента.

См. Ветви поставщика из системы управления версиями с книгой Subversion.