Именованная ранее безымянная ветка

Question

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

Вот рабочий процесс ...

Пользователь A начинает работать с функцией, которую он ожидает небольшой, поэтому он просто начинает работать (из ветви default). Изменение оказывается большим проектом и потребует нескольких участников. Таким образом, UserA выдает ... hg branch "Feature1" и продолжает работать, фиксируя локально необходимые данные.

Пользователь A затем вытаскивает изменения из центрального репо, чтобы он мог нажать.

На этом этапе hg heads возвращает 3 голов? Показывает 2 для default и 1 для Feature1. Первый заголовок для default - это последнее изменение, внесенное другим пользователем в ветке (не имеет значения). Второй заголовок default является коммитом до hg branch "Feature1" коммита.

В центральном репозитории действуют правила, согласно которым допускается только 1 заголовок на ветку , поэтому принудительное нажатие не вариант. Репо не хочет иметь несколько голов на ветке default.

Пользователь A должен иметь возможность отправить эти изменения, чтобы другие пользователи могли видеть ветку Feature1 и помогать. Я не могу найти способ «исправить» это. Я не думаю, что смогу переписать ветку начальных коммитов для функции, прежде чем она была названной веткой.

Я знаю, что первоначальные изменения до того, как именованная ветвь технически относится к ветке по умолчанию, но означает ли это, что они будут головными, пока эта ветка Feature1 не будет объединена?

Answer 1

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

В моем примере, UserA должен обновиться до нежелательного заголовка на default и закрыть эту ветку по умолчанию, так как это нежелательно. Это оставит 2 головы одну для default и одну для Feature1, как и ожидалось.

hg update -r X // X is the rev of the unwanted head.
hg commit --close-branch -m "Moved to Named Branch Feature1, cleaning up initial work"

Затем обновите ветку Feature1, нажмите и продолжите работу.

Другой рабочий процесс почти такой же, за исключением того, что пользователь A решил нажать Feature1, чтобы другие помогли, а default никто не продвинул вперед. Локальное репо имеет только 2 головы, и пользователь может нажимать, но пользователь A НЕ хочет просто нажимать, поскольку наконечник default теперь будет набором изменений, который действительно «принадлежит» Feature1.

Пользователь A должен обновиться до последней, нежелательной ревизии defaul t. Затем верните default обратно к ревизии, прежде чем UserA начнет работать.

hg update default
hg revert -r Y // Y is the changeset before UserA started working on the feature
hg commit -m "Reverting changes that now exist in Feature1 branch"

Затем обновите ветку Feature1, нажмите и продолжите работу.

Answer 2

Мы обнаружили, что это очень большая проблема для нашей команды (выполнение ветвлений для каждой функции), и в конечном итоге остановили работу сценария hgweb.cgi (HTTP 414 Request Long).

Answer 3

Причина, по которой вы видите две головы в ветви default в локальном репо, заключается в том, что после последнего общего предка наборы изменений в центральном репо не имеют ничего общего с наборами изменений в локальном репо. 1002 *

Чтобы решить вашу проблему:

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

   hg clone -r common_ancestor central local2
   

2. Экспорт изменений из первого локального репо. Обратите внимание на двоеточие после first_local_change, чтобы получить все изменения в этом репо.

   cd local1
   hg export -r first_local_change: > ../local1.patch
   

3. Перейдите в новый локальный репозиторий, создайте ветку feature для импорта изменений, затем импортируйте их:

   cd ../local2
   hg branch feature
   hg import ../local1.patch
   

   hg import имеет возможность использовать информацию о ветвях в файле исправления, но по умолчанию она отключена.

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

Answer 4

Не проходите через центральное хранилище. Просто попросите разработчиков проявить друг друга.

Answer 5

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