Обмен изменениями одного файла в hg (не весь набор изменений) - PullRequest
2 голосов
/ 27 апреля 2011

Сценарий:

Настройка корпоративной системы ртути. Разработчики работают над несколькими ветками, по одному на каждого разработчика (больше или меньше). Мы свободно следуем этой модели: https://www.mercurial -scm.org / wiki / ControlledPractice .

Ограничения дизайна / рабочего процесса: репо являются сверхдолгосрочными (более 10 лет); Количество разработчиков на репо находится в диапазоне 10-30.

  • DevA исправляет ошибку в 1 файле.
  • DevB нуждается в исправленном файле, но явно не хочет, чтобы остальная часть работы DevA.

Это произойдет лот , мы ожидаем.

Есть несколько способов справиться с этой ситуацией:

  1. Исправление в одном наборе изменений, которое hg transplant передает из ветви DevA в ветку DevB (или ветвь с кодом общего доступа).
  2. Создает именованную ветку для исправления, порождая начальный коммит DevB, чтобы его можно было без проблем объединить.

Проблемы:

  1. Повторяющиеся наборы изменений могут привести к путанице в том, где была реализована данная функция (но, возможно, нет?).
  2. Изобилие веток после нескольких лет работы над этой кодовой базой = неприемлемо.

Есть ли другие известные способы справиться с этой ситуацией?

Ответы [ 2 ]

3 голосов
/ 27 апреля 2011

Способ справиться с этим - заставить DevA быть более внимательным к родительской ревизии своего изменения. Прежде чем devA исправит исправление, он должен hg update сделать самую раннюю ревизию, в которой это исправление могло быть сделано (часто это набор изменений, в котором была представлена ​​ошибка). Когда Dev A фиксирует сообщение, он / она увидит сообщение о том, что был создан новый руководитель. Эту новую головку затем можно вытащить и объединить с любой веткой или репо, в которых есть ошибка, без чего-либо еще.

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

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

Эти новые головы - то, что некоторые люди называют "анонимными ветвями", и они не распространяются так же, как названные ветви.

1 голос
/ 27 апреля 2011

если вы перемещаете наборы изменений из одной ветви в другую в одном репо, я бы порекомендовал команду transplant. Чтобы узнать, откуда взялась ревизия, вы можете использовать команду --log, чтобы добавить некоторую информацию в сообщение фиксации трансплантата. Например:

hg update default
hg transplant revX --log

создаст набор изменений на default со следующим сообщением о фиксации:

<original commit message of revX>
(transplanted from fa10a36d94385723fc7ecfaacb189365509ee83e)

Я не знаю, как добавить аргумент --log с помощью TortoiseHg v1.1.X, но вы также можете выполнить трансплантацию из графического интерфейса обозревателя репо.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...