Объединение изменений в рабочую область с незафиксированными изменениями

Question

Мы только что перешли с SVN на Mercurial, но сейчас у нас проблемы с нашим рабочим процессом.Пример: у меня есть локальный клон репозитория, над которым я работаю.Я делаю некоторые экспериментальные изменения в нашей кодовой базе, то, что я не хочу фиксировать, прежде чем я уверен, что это работает так, как должно, я не хочу фиксировать это даже локально.Теперь мой коллега сделал несколько значительных улучшений / исправлений ошибок, которые мне нужны.Он помещает свои коммиты в наш главный репозиторий.Вопрос в том, как я могу объединить его изменения с моим рабочим пространством, не требуя, чтобы мне пришлось фиксировать все мои изменения, поскольку мне нужны его изменения для тестирования моего собственного кода?

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

Answer 1

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

hg diff > mylocalchanges.txt
hg revert -a
# Do your merge here, once you are done, import back your local mods
hg import --no-commit mylocalchanges.txt

Answer 2

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

1) Отложить незафиксированные изменения

2)Выполните извлечение и объединение

3) Отмена хранения незафиксированных изменений

Полка эффективно сохраняет ваши незафиксированные изменения как diff (относительно вашего последнего коммита), а затем откатывает эти файлы в вашей локальной рабочей области.Тогда un-shelving затем применяет этот дифференциал, возвращая ваши незафиксированные изменения.

Инструменты, такие как TortoiseHg, имеют встроенную полку.

Answer 3

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

Есть вытягивание, которое берет изменения от какого-то другого клона хранилища и помещает их в ваш клон.

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

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

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

Это дает вам свободу быть в курсе других разработок коллег в вашем проекте, и вам не нужно выпускать свой экспериментальный код, пока он не будет готов (или даже вовсе).

Итак, пока вы держитесь подальше от команды Push, вы в безопасности.

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

Что касается файлов конфигурации, типичный способ сделать это состоит в том, что вы просто фиксируете шаблон основного файла в хранилище с другим именем (т.е. с дополнительным расширением .template или аналогичным), а затем помещаете имя реальный файл конфигурации в фильтр игнорирования.

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

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

Answer 4

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

Что касается конфигурационных файлов, не фиксируйте их.
Зафиксируйте файлы шаблона и скрипт сможет генерировать полные файлы конфигурации из шаблона.
Таким образом, разработчики будут изменять только «личные» (то есть не зафиксированные) файлы конфигурации со своими собственными личными значениями.