Если я начну с локального меркуриального репо, который я считаю "основным" репо (прошу простить меня своим лордам dvcs), и намереваюсь использовать битбакет как средство резервного копирования и отслеживания проблем, я могу сделать все мои изменения в моем локальном репо и сделать "hg push", чтобы отправить изменения обратно в битбакет.
Не нужно ли следовать этой команде "hg push" на моем локальном компьютере с "обновлением hg"?
Почему вам все равно, что в рабочем каталоге на серверах BitBucket? Пока вы нажимаете изменения, вы будете в репозитории и видны на странице BitBucket.
EDIT: Хорошо, я собираюсь изменить это, чтобы быть полезным ответом.
Скажите, что вы клонируете один из моих репозиториев, например django-hoptoad на BitBucket. У вас будет папка с именем django-hoptoad на вашем локальном компьютере, и ее содержимое будет выглядеть примерно так:
django-hoptoad/
|
+-- .hg/
|
+-- ... my code and other folders
Все данные о самом хранилище хранятся в папке .hg/. То, что Mercurial хранит данные о том, какие файлы были изменены, в каких наборах изменений и много других вещей.
Вы можете думать об этом так (хотя это упрощение):
django-hoptoad/
|
+-- .hg/
| |
| +-- data about changeset 1
| +-- data about changeset 2
|
+-- ... my code and other folders as they appear in changeset 2
Когда вы запустите hg pull и не обновляетесь, вы вставляете любые новые изменения в репозиторий:
django-hoptoad/
|
+-- .hg/
| |
| +-- data about changeset 1
| +-- data about changeset 2
| +-- data about changeset 3 (NEW)
| +-- data about changeset 4 (NEW)
|
+-- ... my code and other folders as they appear in changeset 2
Если вы не обновляете, ... my code and other folders по-прежнему будет эквивалентен тому, что находится в changeset 2, но другие изменения все еще находятся в репозитории.
При запуске hg update Mercurial обновит ... my code and other folders до содержимого новейшего набора изменений.
django-hoptoad/
|
+-- .hg/
| |
| +-- data about changeset 1
| +-- data about changeset 2
| +-- data about changeset 3
| +-- data about changeset 4
|
+-- ... my code and other folders as they appear in changeset 4
Действительно, это означает, что то, что происходит в ... my code and other folders, не должно соответствовать тому, что находится в репозитории. Вы можете просто удалить его, и все изменения будут по-прежнему находиться в репозитории:
django-hoptoad/
|
+-- .hg/
|
+-- data about changeset 1
+-- data about changeset 2
+-- data about changeset 3
+-- data about changeset 4
Если вы совершили прямо сейчас, он создаст новый набор изменений, который в основном говорит "без файлов". Однако вам нечего делать. Люди все еще могут оттолкнуться от вас, потому что в хранилище все еще есть данные о наборах изменений.
Это почти наверняка, что делает BitBucket. Вы никогда не заходите на серверы BitBucket, не редактируете свой код и не совершаете его - вы только собираетесь нажимать/тянуть/клонировать. Это означает, что ... my code and other folders никогда не будет использоваться, поэтому я бы предположил, что Jesper настроил его, чтобы удалить его, чтобы сохранить дисковое пространство.
Так как hg update влияет только на рабочий каталог, а рабочий каталог на BitBucket никогда не используется, вам не нужно запускать hg update после нажатия на BitBucket.
Я думаю, что вы можете запутаться между рабочей копией (aka рабочим каталогом) и локальным repository. Это связанные, но разные вещи. Локальный репозиторий содержит полную историю всех отслеживаемых файлов, тогда как рабочая копия содержит версии файлов из определенной версии плюс ваши изменения к ним,
Команда hg push и pull перемещение изменений между репозиториями и update и commit перемещает изменения между вашей рабочей копией и локальным хранилищем.
Итак, если вы push изменились в удаленный репозиторий, который не изменит локальный репозиторий, и поэтому нет необходимости запускать update в локальном репозитории. Тем не менее, любой, кто использует удаленный репозиторий, должен будет сделать update, чтобы ваши изменения отображались в их рабочей копии. И наоборот, если вы pull меняетесь из удаленного репозитория, вам нужно сделать update, чтобы эти изменения отображались в вашей рабочей копии.
Аналогичным образом вам нужно commit все изменения из вашей рабочей копии в локальный репозиторий, прежде чем их можно будет отправить в другой репозиторий с помощью push.
Bitbucket показывает репозиторий . Как отметил Дейв Уэбб, hg update занимается обновлением рабочей копии. Когда вы выполняете hg push, вы переносите ревизии для обновления репозитория на Bitbucket, и поэтому веб-интерфейс покажет это.
На Bitbucket нет рабочих копий, как отметил Стив Лош. За вашей спиной также не выполняется hg update.
Вы можете поэкспериментировать с этим сами, сделав клон без рабочей копии:
% hg clone --noupdate repo repo-empty
перейдите в repo-empty и выполните hg log. Вы увидите, что, хотя там нет файлов, история (т.е. Репозиторий) все еще клонирована. Вы можете сделать файлы с помощью команды hg update:
% hg update
и снова исчезнуть с помощью
% hg update null
Рабочая копия нужна только в том случае, если вы хотите посмотреть файлы и внести новые коммиты. В противном случае вы можете удалить его, чтобы сэкономить место. Обычно это делается в клонах, которые используются только для hg serve или эквивалентной вещи, используемой Bitbucket.
Не нужно делать обновление hg на локальном компьютере. Обновление используется, когда данные переносятся в ваш локальный репозиторий, и вы нажимаете FROM из вашего локального репозитория.