Что делать, если патч для импорта Mercurial не удается?

Ответ 1

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

Другими словами, похоже, что у вас есть следующий случай:

                    +-- you're here
                    |
                    v
1---2---3---4---5---6
     \
      \
       X <-- patch was built to change 2 to X

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

После этих действий репозиторий должен выглядеть следующим образом:

                        +-- you're here
                        |
                        v
1---2---3---4---5---6---8
     \                 /
      \               /
       7-------------/
       ^
       |
       +-- this is the changeset you committed after applying the patch

Теперь, по-другому.

Использует патч только так? Один из распространенных способов использования Mercurial заключается в том, что вы создали свой собственный репозиторий, вилку, изначально состоящую из полного клонирования центрального репозитория, но у вас есть доступ к фиксации.

Таким образом, вы можете перенести свои новые изменения в свой собственный клон.

Если в центральном репозитории появились новые изменения, добавленные после клонирования, в какой-то момент вы вытаскиваете его из своего клона и объединяетесь.

Затем, когда вы удовлетворены, вы выдаете запрос на перенос сторонникам центрального репозитория, сообщая им, что "Эй, у меня есть для вас некоторые изменения, вы можете вытащить их из моего клона здесь: http://...".

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

Это означало бы, что у вас есть два репозитория:

central: 1--2

clone:   1--2

Вы добавляете свою работу:

central: 1--2

clone:   1--2--3

Они добавляют некоторые изменения:

central: 1--2--3--4--5--6

clone:   1--2--3

Затем вы тянете:

central: 1--2--3--4--5--6

clone:   1--2--4--5--6--7
             \
              \
               3  <-- this is your changeset

Затем вы объединяетесь:

central: 1--2--3--4--5--6

clone:   1--2--4--5--6--7--8
             \            /
              \          /
               3--------/

Если пользователи теперь тянут вас, они получают ту же самую историю в своем репозитории.

Там также есть поддержка для перераспределения, что означало бы, что вам не нужно было тянуть и объединять, но сопровождающие будут выдавать команду "pull with rebase", по сути перемещая ваш набор изменений с его текущей позиции на новую позицию в их хранилище, это будет выглядеть так:

central: 1--2--3--4--5--6---7
                            ^
clone:   1--2--3            |  relocated here
               |            |
               +------------+

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

Для получения дополнительной информации о forking, просмотрите видео Tekpub на CodePlex и Mercurial, здесь: Tekpub: 7 - Mercurial With CodePlex, найдите около 21:15 для чтобы начать работу.

Обратите внимание, что "fork" в основном является клоном, способ работы с файлами в CodePlex заключается в том, что он автоматизирует настройку клона в вашей собственной учетной записи и отправляет оригинальным сопровождающим запрос на перенос, но если вы создаете свою собственную учетную запись на Bitbucket или CodePlex или что-то еще, опубликуйте свой клон там и просто отправьте сопровождающим электронное письмо с URL-адресом репозитория, чтобы все было в нем.

Ответ 2

В моем случае мой сбойный импорт hg был связан с окончанием строки. Решение помещало это в мой файл ~/.hgrc:

[patch]
eol = auto