Является ли `hg pull --rebase` аналогичным` svn update`?
Этот вопрос предполагает наличие "благословенного" центрального репозитория, в котором члены команды
- клон из
- нажмите, когда у них есть вклады, которые они хотят видеть в других членах команды.
- тянуть, когда они хотят видеть вклад других людей.
- и др.
Если это так, я бы предположил, что hg update
не похож на svn update
(почему было бы две команды, которые делают то же самое?). Из того, что я могу собрать, hg update
больше нравится svn revert
. Это правильно?
Update:
Мое понимание перебазы во многом основано на разделе "Общий случай" на этой странице:
https://www.mercurial-scm.org/wiki/RebaseProject
Ответы
Ответ 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
, чтобы ваша рабочая копия была такой же, как и ваш локальный репозиторий.