Вопросы Теги

'hg получение по запросу - переоснова', аналогичная 'svn обновление'?

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

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

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

Обновление:

Мое понимание переосновы в основном основано на разделе "A common case" на этой странице:
https://www.mercurial-scm.org/wiki/RebaseProject

22
задан Vadim Kotov 31 May 2017 в 11:52
поделиться

5 ответов

Как указывали другие, почти, но не совсем. В порядке уменьшения сходства с 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 . Сообщество Mercurial предпочитает обновление .
41
ответ дан 29 November 2019 в 03:55
поделиться

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

2
ответ дан 29 November 2019 в 03:55
поделиться

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

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

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

2
ответ дан 29 November 2019 в 03:55
поделиться

Не совсем.

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

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

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

Эквивалентом 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, который клонировал репо A, хочет получить эти изменения, и поэтому делает hg pull непосредственно из репо A.
  3. B использует hg update для обновления своей рабочей копии до изменений.

Также, эквивалентом svn revert является hg revert. :)

.
11
ответ дан 29 November 2019 в 03:55
поделиться 
hg pull --update

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

Как описано в этом SO вопросе

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

Таким образом, в DVCS у вас есть два понятия вместо одного:

  • локальный репозиторий (pull/push)
  • рабочий каталог (который является единственным локальным представлением "вершины" репозитория в SVN)
2
ответ дан 29 November 2019 в 03:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: