Предотвращение перехода нестабильного кода в строку по умолчанию

Question

В настоящее время у меня есть 2 хранилища. Один репозиторий называется jstock, который содержит весь стабильный исходный код.

Другой репозиторий с именем jstock-refactor-calendar-to-joda, который клонирован из jstock и содержит весь нестабильный код экспериментальной функции.

Весь набор изменений в красном прямоугольнике является нестабильным экспериментальным кодом объекта. Они еще не закончены. Следовательно, у меня нет намерения объединить его с набором изменений в зеленом прямоугольнике (зеленый прямоугольник указывает, что это стабильный набор изменений)

После того, как jstock-refactor-calendar-to-joda извлекает из jstock, вот как это выглядит.

Теперь я бы хотел, чтобы экспериментальный код был виден jstock (но не в строке по умолчанию, так как они нестабильны)

Следовательно, когда я выполняю толчок от jstock-refactor-calendar-to-joda до jstock, вот что я получаю.

Теперь весь нестабильный код относится к строке по умолчанию!

Это не то, что я хочу. В jstock мне бы хотелось, чтобы стабильный код (в зеленом прямоугольнике) оставался по умолчанию (слева), а нестабильный код (в красном прямоугольнике) - справа. Обратите внимание, что я не хочу, чтобы они были объединены, но я хотел бы, чтобы обе линии разработки (стабильная и нестабильная) были видимыми.

Есть ли какой-то шаг, который я сделал неправильно?

Answer 1

Это также было опубликовано в списке рассылки Mercurial и ниже: мой ответ :

Расположение двух (анонимных) веток в средстве просмотра журнала не имеет значения: не осталось ни одногоили с правой стороны, порядок зависит только от того, в каком порядке вы выполняли операции вытягивания и подталкивания.

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

• отдельные клоны: Это тривиальный способ, который вы уже использовали, когда вы держите отдельный клон для разных ветвей.

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

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

• именованные ветви: См. мое руководство, если вы еще этого не сделали:

  http://mercurial.aragost.com/kick-start/en/tasks/

  Преимущество именованных веток состоит в том, что они помещают метку в каждую ревизию, чтобы вы могли отслеживать, откуда они берутся.Если у вас есть именованная ветка с именем «refactor-calendar-to-joda», то вы можете сделать

  hg update refactor-calendar-to-joda
  

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

  Чтобы вернуться к ветви по умолчанию, выexecute

   hg update default
  

  Это то место, где должна происходить нормальная разработка.

  Именованные ветви хороши для ветвей, которые стабильны в течение более длительного времени или когда имя также имеет смысл спустя годы.Например, если вы используете трекер ошибок, я предлагаю создать ошибку для отслеживания рефакторинга, а затем вызвать ветку «ошибка XX».Таким образом, в будущем люди смогут найти правильный номер ошибки.

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

  hg update refactor-calendar-to-joda
  

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

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

Наконец, см. это руководство для получения дополнительной информации по этой теме:

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Answer 2

В этом случае вам нужно нажать «force», когда вы создали несколько голов. Обе эти головки находятся в ветви "по умолчанию".Нет проблем с этим как таковым, но проблема, о которой вы беспокоитесь, заключается в том, что ваша новая голова (с нестабильным кодом) является «подсказкой» ветки по умолчанию.

Из Mercurial FAQ :

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

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

hg update -r 12345

(где 12345 - номер редакции«Вместо ограничения валюты ...»

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

Answer 3

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

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-anonymously

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

Когда люди hg update default или просто hg update переместились в самый новый набор изменений в ветви default, просто сделайте еще один коммит с набором изменений "Вместо ограничения числа знаков после запятой ..." в качестве его родителя это:

hg update REVSION
...edit
hg commit

И они будут автоматически обновляться до нужной вам анонимной ветви при клонировании / обновлении.

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

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

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-with-bookmarks

Answer 4

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

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

Другими словами, все наборы изменений, которые вы видите там, являются частью ветви default, однако метка показана только для кончика этой ветви. Поскольку новые ревизии теперь являются подсказкой, именно там в интерфейсе отображается метка.

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

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