Что самый легкий путь состоит в том, чтобы фиксировать и продвинуть единственный файл при оставлении других модификаций в покое?

tl; доктор: Мое исходное объяснение выглядит сложным, но я надеюсь, что оно полностью объясняет, как использовать очередь патча. Вот короткая версия:

$ hg qnew -m "migration notes" -f migration my_migration.sql
$ hg qnew -f working-code
# make some changes to your code
$ hg qrefresh # update the patch with the changes you just made
$ hg qfinish -a # turn all the applied patches into normal hg commits

Подвижные Очереди делают этот вид вещи бризом, и это делает более сложное управление changesets возможным. Это стоит изучить.

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

# create a patch called migration containing your migration
$ hg qnew -m "migration notes" -f migration.patch my_migration.sql
$ hg qseries -v # the current state of the patch queue, A means applied
0 A migration.patch
$ hg qnew -f working-code.patch # put the rest of the code in a patch
$ hg qseries -v
0 A migration.patch
1 A working-code.patch

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

$ hg qtop # show the patch we're currently editing
working-code.patch
$ ...hack, hack, hack...
$ hg diff # show the changes that have not been incorporated into the patch
blah, blah
$ hg qrefresh # update the patch with the changes you just made
$ hg qdiff # show the top patch's diff

, поскольку вся Ваша работа сохраняется в очереди патча теперь, можно не применить те изменения и восстановить их после получения по запросу в удаленных изменениях. Обычно для неприменения всех патчей просто сделайте hg qpop -a. Только для показа влияния на очередь патча я вытолкаю их прочь по одному.

$ hg qpop # unapply the top patch, U means unapplied
$ hg qseries -v
0 A migration.patch
1 U working-code.patch
$ hg qtop
migration.patch
$ hg qpop
$ hg qseries -v
0 U migration.patch
1 U working-code.patch

На данном этапе это - как будто нет никаких изменений в Вашем каталоге. Сделайте hg fetch. Теперь можно продвинуть очередь патча, возвращается на, и объедините их, если существуют какие-либо конфликты. Это концептуально несколько подобно перебазе мерзавца.

$ hg qpush # put the first patch back on
$ hg qseries -v
0 A migration.patch
1 U working-code.patch
$ hg qfinish -a # turn all the applied patches into normal hg commits
$ hg qseries -v
0 U working-code.patch
$ hg out
migration.patch commit info... blah, blah
$ hg push # push out your changes

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

$ hg qpush
$ hg qseries -v
0 A working-code.patch
$ hg export qtip > temp.diff
$ rm -r .hg/patches # get rid of mq from the repository entirely
$ hg import --no-commit temp.diff # apply the changes to the working directory
$ rm temp.diff

я чрезвычайно увлекаются для исправления очередей для разработки, и mq одна из самых хороших реализаций там. Способность обработать несколько изменений одновременно действительно улучшается, как сфокусированный и убирают, Ваши фиксации. Это требует времени для привыкания к, но это идет невероятно хорошо с рабочим процессом DVCS.

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

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

Прошло почти 2 года с тех пор, как я первоначально задал этот вопрос. Сейчас я бы сделал это по-другому (как я упоминал в комментарии над вопросом выше). Сейчас я бы сделал так: вместо фиксации изменений в одном файле в локальном репозитории (вы можете использовать расширение hg record, чтобы фиксировать только части файла):

hg commit -m "commit message" filename

Затем просто выкладываю.

hg push

Если возникнет конфликт из-за того, что в репозиторий были внесены другие изменения, которые мне нужно сначала объединить, я бы обновился до родительской ревизии (можно посмотреть с помощью "hg parents -r .", если вы не знаете, что это такое), зафиксировал бы там свои другие изменения, чтобы у меня было две головы. Затем возвращаюсь к исходному однофайловому коммиту и переношу/сливаю изменения в эту версию. Затем вытолкните изменения с помощью

hg push --rev .

Чтобы вытолкнуть только один файл и слияние этой ревизии. Затем вы можете объединить две головы, которые у вас есть локально.

Этот способ позволяет избавиться от mq и потенциальной возможности отклоненных hunks и сохранить все, что отслеживается в системе контроля исходного кода. Вы также можете "hg strip" удалить ревизии, если позже решите, что они вам не нужны.