Подтвердить что ты не робот

Является ли `hg pull --rebase` аналогичным` svn update`?

Этот вопрос предполагает наличие "благословенного" центрального репозитория, в котором члены команды

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

Если это так, я бы предположил, что hg update не похож на svn update (почему было бы две команды, которые делают то же самое?). Из того, что я могу собрать, hg update больше нравится svn revert. Это правильно?

Update:

Мое понимание перебазы во многом основано на разделе "Общий случай" на этой странице:
https://www.mercurial-scm.org/wiki/RebaseProject

4b9b3361

Ответ 1

Как указывали другие, почти, но не совсем. В порядке убывания сходства с svn update (и увеличения соответствия общим DVCS, и особенно Mercurial, лучшей практики [1]):

  • hg pull -u (или hg pull, за которым следует hg update), при этом ваши изменения не будут отменены и не будут исправлены с момента последнего нажатия. Это как можно ближе к svn update, как вы можете получить, но это довольно плохой метод DVCS. Одна из тонкостей DVCS заключается в том, что вы можете зафиксировать свои изменения, прежде чем пытаться объединить их с другими, и, таким образом, иметь резервную версию для отката и повторить неудавшееся слияние, и эта практика дает это. Не делайте этого.

  • hg pull --rebase после внесения изменений. Это подталкивает вверх по течению изменения, повторно применяет ваши изменения поверх них и позволяет вам отодвигать ваши изменения в виде линейной истории. Конечный результат будет очень похож на историю ревизий Subversion, но вы получите преимущество DVCS в совершении перед слиянием. Я не знаю, насколько безопасность этого режима работы сравнивается между Mercurial и Git; в Git, варианты досрочной замены ваших изменений будут по-прежнему присутствовать до тех пор, пока вы не выполните git gc, но Mercurial не имеет явной защитной сети gc.

  • hg pull, а затем hg merge с вашими изменениями, уже внесенными в вашу локальную копию. Это традиционная практика Mercurial для выполнения функционального аналога svn update, несмотря на нижеследующую сноску 1 ниже. Это приводит к нелинейной истории версий, но все изменения отслеживаются и проверяются.

Тем не менее, есть много мудрости, думая о Mercurial (и других DVCS) на своих собственных условиях, и не пытается перевестись из мышления Subversion/CVS.

  • Если вы не из переписываемой истории, чтобы сохранить эту линейную школу мысли. Если вы, то rebase, вероятно, предпочтительнее update. Сообщество Mercurial склоняется к update.

Ответ 2

Не совсем.

hg pull захватывает ревизии из другого репозитория и добавляет их к локально доступным версиям в вашем клоне репозитория, но не обновляет вашу рабочую копию - только ваш репозиторий (который для DCVS, например hg/ git/etc - это не то же самое, что рабочая копия).

hg update обновляет вашу фактическую рабочую копию до последней версии в вашем локальном репозитории.

Это отличается от Subversion, потому что в svn нет такой вещи, как ваш "локальный репозиторий" - единственный репозиторий - тот, что на сервере; у вас есть только рабочая копия локально. Следовательно, почему update - это только одна команда, а не Mercurial pull, а затем update.

Эквивалент svn update для Mercurial будет hg pull --update, что эквивалентно выполнению hg pull, а затем hg update один за другим.

Целый рабочий процесс для DCVS с "центральным" репо выглядит примерно так:

  • A выполняет hg commit при некоторых изменениях.
  • A делает hg push, чтобы вытолкнуть их в центральный репозиторий.
  • B делает hg pull, чтобы вытащить их из центрального репозитория в свой собственный клон.
  • B делает hg update для обновления своей рабочей копии, чтобы отразить изменения, внесенные в их клон.

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

  • A выполняет hg commit при некоторых изменениях.
  • B, который клонировал репо, хочет эти изменения и, следовательно, делает hg pull непосредственно из репо.
  • B использует hg update для обновления своей рабочей копии до изменений.

Кроме того, эквивалент svn revert равен hg revert.:)

Ответ 3

hg pull --update

будет эквивалентом svn update

Как описано в этом вопросе fooobar.com/questions/232099/...

Команда hg push и pull перемещение изменений между репозиториями и update и commit перемещает изменения между вашей рабочей копией и локальным репозиторием.

Итак, в DVCS у вас есть 2 понятия вместо одного:

  • локальное репо (pull/push)
  • рабочий каталог (который является единственным локальным представлением "подсказки" репо с SVN)

Ответ 4

Здесь отличный справочник начинающих по меркуриальному http://hginit.com/. Должно объяснять многое. Начиная с "Не пытайтесь применять svn-знания для распространения vcs"!

Ответ 5

Команда hg pull --rebase не совсем аналогична svn update, но результат может быть одинаков.

В Subversion, если вы обновляете свою рабочую копию, вы получаете последние изменения в репозитории, объединенные с любыми локальными изменениями. Таким образом, файлы в вашем репозитории обновляются, но вы все еще можете иметь незафиксированные изменения.

В Mercurial, hg pull --rebase, вы получите последние изменения из "центрального репозитория" (или любого другого репозитория, из которого вы вытаскиваете), чтобы обновить ваш репозиторий, а затем перетасовать ваши локальные коммиты. Вам все равно понадобится hg update, чтобы ваша рабочая копия была такой же, как и ваш локальный репозиторий.