Mercurial фиксирует сообщения из локального в центральное хранилище - PullRequest
3 голосов
/ 17 августа 2010

Я недавно начал использовать Mercurial, и мне нравится, как у меня есть защита VCS для моей индивидуальной разработки, не регистрируя ее в центральном репозитории, затем я перехожу к центральному репо, когда у меня есть что-то готовое для остальной команды.

Когда я "hg commit", я пишу сообщение о коммите, относящееся к добавлению с момента последнего коммита.У меня может быть 5 или около того локальных коммитов, прежде чем я буду готов выдвинуть материал к центральному.Когда я делаю push, если я не указываю ревизию, все мои локальные коммиты и их сообщения добавляются в центральный репозиторий, но я не хочу загромождать центральный журнал всеми моими локальными шагами smalls.Когда я нажимаю и указываю локальную ревизию, я думаю, что только эта ревизия и ее сообщение о фиксации выдвигаются, верно?

Проблема в том, что я хочу нажать с сообщением о фиксации, которое обобщает все мои локальные "офлайн"работать, потому что это то, что я действительно добавляю.Однако, сообщение коммита, которое выдвигается, является тем, что я написал недавно.Скажем, я работаю над функцией А, и у меня есть пять локальных коммитов для нее;«Добавлено A.1» «Добавлено A.2» «Очистить код в foo.cpp» и т. Д., Оканчиваясь на «Добавлено A.4».Я хочу, чтобы зарегистрировался в центральном репозитории: «Добавлен A, очищен foo.cpp», но если я нажму последнюю версию, он просто увидит «Добавленный А.4».Теперь, когда произошли обновления для централизованного сервера, мне нужно локально слиться, прежде чем я отправлю, мое локальное сообщение коммита «Объединено в подсказку».Понятно, что это не очень хорошее сообщение о коммите, чтобы отодвинуть его назад.

Что здесь хорошего?Мне неизвестен какой-либо механизм изменения существующего сообщения о коммите или отправки нового сообщения о коммите.Я не хочу вносить тривиальные изменения в мое локальное хранилище, просто чтобы ввести новое сообщение о коммите перед изменением;это просто глупо.Я должен что-то упустить, потому что это кажется основным.Или я не думаю о Mercurial правильно?

Ответы [ 4 ]

2 голосов
/ 17 августа 2010

Вы ищете расширение Mercurial Queues . В Mercurial: полное руководство , главы 12 и 13 подробно описывают их.

1 голос
/ 18 августа 2010

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

Существуют некоторые расширения ( collapse , rebase , histedit , mq ), которые позволяют изменять наборы изменений после факта.Расширение collapse - это то, что вам нужно: оно позволяет вам свернуть (объединить) пять локальных наборов изменений в один набор изменений, который затем можно отправить на сервер.

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

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

1 голос
/ 17 августа 2010

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

Если вы хотите отправить один набор изменений (и он не зависит от своих предков), вы можете изменить порядок своей локальной истории, чтобынабор изменений, который вы хотите отправить, является предком.Расширение histedit позволит это сделать.Если вы хотите сжать свои локальные изменения и отправить их как один набор изменений, вы можете «сложить» их вместе, используя histedit.

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

Очереди являются (хорошим / популярным) решением, но предназначены для решения несколько другой проблемы (поддержка исправлений для другого репозитория).).Конечно, я говорю, что никогда не использовал расширение mq.Если вы действительно хотите, чтобы локальная история отличалась от центральной (например, поддержание всех ваших локальных сообщений), то очереди - единственное решение, о котором я знаю.

1 голос
/ 17 августа 2010

Я не верю, что Mercurial поддерживает эту форму набора функций. Лучший способ добиться этого - это:

1) После внесения изменений клонируйте свой «центральный» репозиторий в новую папку.
2) Экспортируйте файлы патчей со всеми вашими изменениями из исходного рабочего репозитория.
3) Импортируйте файлы патчей в вашу новую клонированную нетронутую папку.
4) Зафиксируйте все изменения сразу во вновь клонированной папке и отправьте эти изменения.

Создание сценария для выполнения этих шагов не должно быть слишком сложным!

...