MQ против филиалов в Mercurial - PullRequest
9 голосов
/ 12 марта 2012

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

Сегодня я читаю о MQ (Mercurial Queues - главы 12 и 13 ). Я думаю, что понял концепцию MQ, поэтому мой вопрос:

Есть ли какое-либо преимущество MQ над (именованными) ветками в Mercurial (для моего сценария)?

Ответы [ 2 ]

13 голосов
/ 12 марта 2012

Основным преимуществом MQ над именованными ветвями являются:

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

  • Изменения в ваших патчах будут четко отделены от изменений, внесенных в апстрим. Когда вы объединяете две ветви, вы смешиваете два потока развития. Это затрудняет просмотр изменений, которые вы внесли, не видя изменений, поступающих из ветки upstream.

  • Имена патчей временные. Когда вы hg qfinish применили патч, в коммите не осталось и следа от названия патча. Таким образом, вы можете использовать MQ без предварительной координации с репозиторием в восходящем направлении, поскольку они никогда не заметят MQ.

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

  • У вас нет постоянного имени ветви в наборах изменений. Люди иногда рассматривают именованные ветви как одноразовые и расстраиваются, когда понимают, что именованная ветвь зафиксирована в истории. (На самом деле вы можете установить имя ветки с помощью hg branch перед установкой патчей, так что этот момент не так уж и плох.)

Недостатки MQ:

  • Это дополнительный инструмент для изучения. Это мощный инструмент, но он также дает вам больше возможностей выстрелить себе в ногу. Запуск hg qdelete действительно удалит патч, и вы сможете выбросить данные. (Я думаю, что это нормально, но у нас есть пользователь Git, приходящий в наш список рассылки, жалующийся на это.)

  • Вы затрудняете сотрудничество с другими. Вы можете превратить .hg/patches в репозиторий и извлекать патчи между репозиториями, но это трудно сделать, если вы являетесь более чем одним разработчиком. Проблема в том, что вы в конечном итоге объединяете патчи, если более одного человека обновляют один и тот же патч.

  • У вас нет постоянного имени ветви в наборах изменений. Если вы правильно используете именованные ветви и используете стабильные, долгосрочные имена ветвей, то при использовании MQ вы упустите это.

1 голос
/ 12 марта 2012

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

MQ - отличный инструмент, с большой мощностью и большими подводными камнями.Вы также можете рассмотреть возможность использования pbranch .

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

Закладки (или ветки, если хотите) хороши для короткой задачи разработки, которую необходимо объединить с вышестоящим кодом.

...