Сообщения коммитов Mercurial из локального в центральный репозиторий

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

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

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

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


version-control mercurial
person jasper77    schedule 17.08.2010    source источник

Ответы (4)


arrow_upward
1
arrow_downward

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

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

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

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

person Martin Geisler    schedule 17.08.2010
comment
Я выбрал это решение, потому что похоже, что коллапс - это действительно то, что я ищу. Это позволит мне отказаться от любых небольших улучшений, которые я делаю локально, а затем привести в порядок один или несколько более полных наборов изменений, прежде чем делиться своими обновлениями. Я понимаю, что в некоторых случаях это может ослабить слияние Mercurial, если он больше не сможет видеть все мелкие шаги, предпринятые, поэтому я буду осторожен. Спасибо. - person jasper77; 18.08.2010

arrow_upward
2
arrow_downward

Вы ищете расширение Mercurial Queues. В Mercurial: The Definitive Guide, главы 12 и 13 подробно их рассмотрим.

person Niall C.    schedule 17.08.2010

arrow_upward
1
arrow_downward

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

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

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

person Christopher WJ Rueber    schedule 17.08.2010
comment
Клон находится над ssh, поэтому сценарий должен быть интерактивным, но похоже, что этот подход сработает. Спасибо! Разве это не общепринятая модель использования? - person jasper77; 17.08.2010

arrow_upward
1
arrow_downward

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

Если вы хотите отправить один набор изменений (и он не зависит от его предков), вы можете изменить порядок своей локальной истории, чтобы набор изменений, который вы хотите отправить, был предком. Это позволяет histedit. Если вы хотите сжать локальные изменения и отправить их как единый набор изменений, вы можете «сложить» их вместе с помощью histedit.

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

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

person Kirk Kelsey    schedule 17.08.2010