Названное ранее ответвление без имени
Кажется, что именование ранее ответвления без имени действительно не удается. Это создает противную проблему многосекционных головок, для которой я не могу найти решение.
Вот рабочий процесс...
Усера начинает работать над функцией, что они ожидают быть маленькими, таким образом, они только начнут работать (прочь default ответвление). Изменение оказывается крупным проектом и будет нужно в нескольких участниках. Так проблемы Усера... hg branch "Feature1" и продолжает работать, фиксируя локально s необходимый.
Усера затем раскрывает изменения от центрального repo, таким образом, он может продвинуть.
На данном этапе, почему делает hg heads возвратить 3 головы? Это показывает 2 для default и 1 для Feature1. Первая голова для default последнее изменение другим пользователем на (не важном) ответвлении. Второе default голова является фиксацией до hg branch "Feature1" фиксация.
Центральный репозиторий имеет правила, осуществленные так, чтобы только 1 голове на ответвление разрешили, так принуждение нажатия не является опцией. repo не хочет многосекционные головки на default ответвление.
Усера должен смочь продвинуть эти изменения так, чтобы другие пользователи видели Feature1 перейдите и выручите. Я, может казаться, не нахожу способ "исправить" это. Я не думаю, что могу переписать ответвление начальных фиксаций для функции, прежде чем это было именованное ответвление.
Я знаю начальные изменения, прежде чем именованное ответвление будет технически на ответвлении по умолчанию, но делает это означает, что они будут главами до этого Feature1 ответвление объединяется?
3 ответа
Я нашел решение, в котором не нужно повторно клонировать и объединять изменения. Я предпочитаю этот метод в основном для исторических целей, поскольку считаю, что это ценная информация о том, что произошло с функцией (то есть сначала она была небольшой, а затем была пересмотрена. чтобы быть больше и т. д.)
В моем примере UserA должен обновиться до нежелательного заголовка на default и закрыть эту ветвь default, так как это нежелательно. В результате останется 2 головы: одна для по умолчанию и одна для 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 головки, и пользователь может нажимать, но UserA НЕ хочет просто нажимать, поскольку кончик default теперь будет набором изменений, который действительно «принадлежит» Feature1 .
UserA следует обновить до последнего нежелательного набора изменений defaul t. Затем верните значение по умолчанию обратно в ревизию до того, как 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 , нажмите и продолжайте работу.
Причина, по которой вы видите две головы на ветке default в локальном репозитории, заключается в том, что после последнего общего предка наборы изменений в центральном репозитории не имеют ничего общего с наборами изменений в локальном репозитории.
Чтобы решить вашу проблему:
Создайте новый локальный клон центрального репозитория на любой ревизии, которую вы хотите (вероятно, будет проще, если вы будете использовать самого последнего общего предка).
hg clone -r common_ancestor central local2Экспортируйте изменения из первого локального репозитория. Обратите внимание на двоеточие после
first_local_change, чтобы получить все изменения в этом репозитории.cd local1 hg export -r first_local_change: > ../local1.patchПерейдите в новый локальный репозиторий, создайте ветку
featureдля импорта изменений, затем импортируйте их:cd ../local2 hg branch feature hg import ../local1.patchhg importимеет возможность использовать информацию о ветке в файле патча, но по умолчанию она отключена.
На этом этапе вы можете продолжать использовать новое локальное репо вместо оригинального. Также я бы дважды проверил, чтобы убедиться, что в новом репо все так, как должно быть.
from hg help heads: hg heads без args покажет головы ветвей, которые по определению являются наборами изменений, не имеющими дочерних элементов в той же ветви. hg heads --topo должен дать результат, который вам нужен в этом случае.