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

Question

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

1. клон из
2. подталкивают к тому, что у них есть материалы, которые они хотят видеть другими членами команды
3. отрываться от того, когда они хотят видеть вклады других людей.
4. и т.д.

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

Обновление:

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

Answer 1

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

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

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

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

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

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

Answer 2

Не совсем.

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

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

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

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

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

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

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

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

Также эквивалент svn revert равен hg revert. :)

Answer 3

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

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

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

Answer 4

Вот отличное руководство для начинающих по ртути http://hginit.com/. Следует объяснить большинство вещей ясно. Начиная с «Не пытайтесь применять знания SVN к распределенным vcs»!

Answer 5

hg pull --update

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

Как описано в этом ТАК вопрос

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

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

• локальное репо (тянуть / толкать)
• рабочий каталог (который является единственным локальным представлением «наконечника» репо с SVN)