Mercurial: как узнать разницу между моей рабочей копией и другой копией - PullRequest
4 голосов
/ 05 ноября 2011

Я новичок в Mercurial и в основном работал с Clearcase.

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

Есть ли способ сделать hg diff между рабочей копией и другой?

Ответы [ 4 ]

8 голосов
/ 08 ноября 2011

Вы можете проверить, какие изменения есть в другом хранилище, используя:

hg incoming path

Это в основном похоже на pull, но на самом деле не тянет.

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

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

После того, как изменения внесены в ваш репозиторий, вы можете использовать diff, чтобы сравнить их с вашей рабочей копией, как обычно.

hg diff -r tip
2 голосов
/ 05 ноября 2011

s, есть ли способ сделать hg diff между рабочей копией и другой?

Нет.diff сравнивает две ревизии из репо .В вашем случае вы можете использовать вслепую (получать обновления для репо), но избегайте автоматического обновления | слияния вашей рабочей копии.С синхронизированным репо вы можете использовать hg diff, hg update, hg merge вручную, когда и если это необходимо.Вы также можете ничего не делать и фиксировать свои изменения - у вас будет только анонимная ветка и дополнительная голова в репо

2 голосов
/ 06 ноября 2011

Прежде всего, вы должны зафиксировать свои изменения, прежде чем делать что-либо.Я никогда не работал с ClearCase, но я думаю, что он должен работать как SVN, прости меня, если я ошибаюсь.Одним из величайших преимуществ DVCS над CVCS является то, что он позволяет зафиксировать сначала и решить, что делать позже.Это очень важно, потому что вы сначала консолидируете свою работу, а если после слияния все становится слишком запутанным, ваша работа в хранилище безопасна.В худшем кенарио вы можете даже отказаться от грязного слияния и начать все заново.И даже после слияния, версия вашей оригинальной работы (до слияния) будет там, очень важно проверить, не вызвало ли это слияние какую-либо проблему.В SVN (и при условии, что ClearCase похожа) все наоборот: он не разрешает коммит без обновления и слияния ... Я ненавижу это!

Еще одна вещь, команда pull в mercurial не меняетсячто-нибудь в рабочем каталоге.Он просто вносит изменения в локальный репозиторий.Поэтому, по моему мнению, вы должны:

  1. Commit
  2. Pull, с рабочей копией ничего не произойдет
  3. Теперь вы можете проверить журнал, сравнить ревизиии решить, что и как делать, не рискуя потерять работу.Если вы решите, что не будете сливаться сейчас, это нормально, вам не нужно объединять вещи только потому, что вы вытянули другие ревизии (хотя рекомендуется часто выполнять слияние, чтобы избежать головной боли при слиянии очень разных ревизий)*
0 голосов
/ 05 ноября 2011

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

См. Здесь .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...