Создание и использование Mercurial Patch

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

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

Я все еще изучаю hg patch, чтобы решить эту проблему. Было бы полезно, если бы кто-то мог подтвердить, что создание и добавление патча - правильный подход к этому, любые ресурсы, объясняющие этот процесс, будут очень полезны.

Ответ 1

Я бы сначала сделал копии всего, чтобы у вас был способ отступить.

Затем в рабочей копии с изменениями я сначала удалю каталог .hg, а затем скопирую в каталог .hg из нового репо. Это в основном переносит все измененные файлы в новое репо без необходимости удаления любых файлов и каталогов.

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

Как только это будет сделано, зафиксируйте свои изменения и нажмите, если необходимо.

Ответ 2

Вы правы - патч - это то, что вам нужно передать информацию из одного репозитория в другой (несвязанный) репозиторий. Это будет работать, поскольку файлы совпадают, как вы заметили.

Итак, чтобы перенести ваши незафиксированные изменения из вашего клона old, вы делаете

$ hg diff -g > uncommited.patch
$ cd ../new
$ hg patch --no-commit ../old/uncomitted.patch

Это приведет к восстановлению информации, сохраненной в патче. Сюда входит информация о файлах, которые добавлены или переименованы в старый клон.

Ответ 3

Следующие этапы могут выполняться со стандартной установкой Mercurial:

  • Зафиксировать изменения в локальном репозитории. Обратите внимание на номер версии.
  • Используйте "hg export -r REV > patch.diff" для создания патча.
  • Клонировать новый репозиторий.
  • Используйте "hg import patch.diff", чтобы применить исправление к новому репозиторию.

Пример

C:\>hg init example
C:\>cd example
C:\example>echo >file1
C:\example>hg ci -Am file1
adding file1

C:\example>hg clone . ..\example2
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

C:\example>rd /s/q .hg
C:\example>hg init
C:\example>hg ci -Am same-but-different
adding file1

В этот момент example и example2 имеют одинаковое содержимое, но репозитории не связаны друг с другом из-за удаления и повторной инициализации папки .hg.

Теперь внесите некоторые изменения и скопируйте их в один из репозиториев, затем экспортируйте их как патч:

C:\example>echo >>file1
C:\example>echo >file2
C:\example>hg ci -Am changes
adding file2

C:\example>hg export -r 1 >patch.diff

Ниже показано, что другой репозиторий не может вытащить изменения из-за повторной инициализации. Однако он может успешно применить патч:

C:\example>cd ..\example2
C:\example2>hg pull
pulling from c:\example
searching for changes
abort: repository is unrelated

C:\example2>hg import ..\example\patch.diff
applying ..\example\patch.diff

Ответ 4

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

$ hg qinit -c # initialize mq for your repo containing the uncommitted changes 
$ hg qnew name_of_patch # create patch that contains your uncommitted changes
$ hg qpop # resets your working dir back to the parent changeset

не беспокойтесь, ваши изменения безопасны и звучат в .hg/patches/name_of_patch, чтобы убедиться сами.

$ cat .hg/patches/name_of_patch

теперь вытащите новый репо

$ hg pull -u http://location.of.new/repo # pull in changes from new repo update working dir

$ hg qpush # apply your uncommitted changes to new repo

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

$ hg qfinish -a # change all applied patches to changeset

И тогда, если вы хотите....

$ hg push http://location.of.new/repo

Если репозитории не связаны друг с другом, просто запустите репозиторий патча на новом репо. и вручную скопируйте патч и добавьте его в файл .hg/patches/series.

предполагается, что патч был создан. clone new repo

$ hg clone http://location.of.new/repo ./new_repo

init patch repo

$ cd ./new_repo && hg qinit -c

скопировать патч

$ cp ../old_repo/.hg/patches/name_of_patch .hg/patches/

редактируйте файл серии с помощью какого-либо редактора

$ your_favorite_editor .hg/patches/series

name_of_patch   # <---put this in the series file

применить патч к новому репо

$ hg qpush

если нет конфликтов слияния, и вы уверены, что он работает

$ hg qfinish -a

Ответ 5

Если макет тот же, вы можете просто скопировать все файлы (исключая .hg), а затем использовать hg addrem.

Ответ 6

Попробуйте заглянуть в плагин MQ, он делает именно это, если вспомню. Я никогда не использовал это, поэтому не могу сказать.

Ответ 7

Если старый репозиторий был просто перемещен/клонирован на новый URL-адрес, вы можете просто изменить удаленный репозиторий, с которым вы разговариваете с новым.

Если, однако, он был воссоздан с нуля (даже с той же структурой), то я не считаю, что Mercurial имеет встроенные функции, которые помогут вам здесь. Mercurial patches ссылаются на конкретные изменения, которые не будут существовать в вашем новом репозитории.

Вы можете использовать инструмент слияния для выполнения diff и выполнить любые сделанные вами изменения.

Отредактировано Чтобы ответить на вопрос в комментарии: Когда вы клонируете репозиторий, вы делаете полный моментальный снимок всей истории изменений - вместе с соответствующими идентификаторами набора изменений и т.д.

Меркуриальные треки изменяются с помощью наборов изменений в репозиторий, а не на уровне файла, таком как Subversion.

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

Если вы воссоздали репозиторий, идентификаторы изменений не будут совпадать и не могут быть объединены в Hg. Единственным вариантом в этом случае было бы использовать инструмент Merge, который позволит вам увидеть несоответствия в структуре файлов/папок.

Также: стоит указать http://hginit.com/, потому что он объясняет (косвенно) некоторые из этих.