Правильная (лучшая практика?) Процедура для синхронизации с удаленным хранилищем Mercurial? - PullRequest
5 голосов
/ 06 января 2011

Как бывший пользователь Subversion, мы решили перейти на Mercurial для SCM, и это нас немного смущает.Несмотря на то, что Mercurial является распределенным инструментом SCM, мы используем удаленное хранилище для хранения резервных копий изменений, которые мы вносим на сервере, но мы находим несколько проблем с прорезыванием зубов.

Например, когда двое или трое из нас работают над нашимлокальные репо, мы фиксируем, затем нажимаем на удаленное репо, мы обнаруживаем, что создано много голов (?).Это чертовски смутило нас, и нам пришлось провести слияние и т. Д., Чтобы разобраться в этом.

Каков наилучший способ избежать такого количества голов и поддерживать синхронизацию удаленного репо с несколькими разработчиками?

Сегодня я работаю так:

  1. Изменить файл.
  2. Извлечь из удаленного репо.
  3. Обновить локальную рабочую копию.
  4. Слияние?(почему?)
  5. Зафиксируйте мои изменения в локальном репо.
  6. Перейдите к удаленному репо.

Это лучшее решение?

Хотя сегодня это работало нормально, я не могу избавиться от ощущения, что я делаю это неправильно!Честно говоря, я не понимаю, почему слияние вообще нужно делать на этапе извлечения, потому что другие люди работают с разными файлами?

Кроме того, чтобы сообщить RTFM, есть ли у вас какие-либо советы по использованию Mercurial?далеко?Какие-нибудь хорошие онлайн-ресурсы для информации о том, почему у нас так много голов?

ПРИМЕЧАНИЕ. Я прочитал руководство, но оно не дает подробных сведений, и я не думаю, что хочу начать другоебронь на минуту.

Ответы [ 3 ]

11 голосов
/ 06 января 2011

Вы обязательно должны найти некоторые учебные ресурсы.

Я могу порекомендовать следующее:

Что касается вашего конкретного вопроса, "это лучшая процедура", то я бы сказал нет.

Вот несколько советов.

Прежде всего, вам не нужно постоянно оставаться "синхронизированным" с центральным хранилищем.Вместо этого следуйте этим рекомендациям:

  • Перейдите из локального хранилища в центральное, когда вы будете довольны внесенными изменениями.Помните, что это может быть несколько наборов изменений
  • Потяните, если вам нужны изменения, которые другие сделали сразу, т.е.есть исправление, исправленное вашим коллегой, которое вам нужно, чтобы продолжить свою собственную работу.
  • Потяните до толчка
  • Объедините любые дополнительные головки, которые вы сняли, с вашими собственными изменениями,перед тем, как нажать или продолжить работу

Другими словами, вот типичный день.

Вы извлекаете последние изменения, когда приходите утром, чтобы получитьна сегодняшний день местный клон.Вы можете не всегда делать это, если вы находитесь в середине больших изменений, которые вы не закончили вчера.

Тогда вы начинаете работать.Вы фиксируете небольшие наборы изменений с изолированными изменениями. Это не значит, что вы делите большее исправление на множество коммитов меньшего размера только потому, что вы изменяете несколько файлов, но стараетесь избегать исправления более чем одной ошибки за раз или реализации более чем одной функциивовремя.Постарайтесь оставаться сосредоточенным.

Затем, когда вы довольны всеми наборами изменений, добавленными локально, вы решаете отправить их на сервер.Когда вы пытаетесь это сделать, вы получаете сообщение об отмене, в котором говорится, что на сервер будут выдвинуты дополнительные головки, и это не разрешено, поэтому push отменяется.

Вместо этого вы вытягиваете.Это всегда можно сделать, но, конечно, теперь добавляются дополнительные головки в вашем локальном клоне, а не на сервере.

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

Затем вы нажимаете, и теперь это должно быть успешным.В случае, если кому-то удастся отправить больше наборов изменений в центральный репозиторий, пока вы заняты слиянием, вы получите еще один прерыватель, и вам придется промыть и повторить.

История теперь будет отображать несколько параллельных ветвей разработки., но всегда должен оставаться на максимум 1 голова в вашем центральном хранилище.Если позже вы начнете использовать именованные ветви, у вас может быть 1 заголовок на каждую именованную ветку, но старайтесь избегать этого до тех пор, пока не освоитесь только с веткой по умолчанию.

Что касается необходимости слияния?Ну, Mercurial всегда работает с ревизиями, которые являются снимками всего проекта, что означает, что две ветви, даже если они содержат изменения в разных файлах, на самом деле считаются двумя разными версиями всего проекта, и вы должны сказать Mercurial, что он должен объединятьчтобы вернуться к одной версии.

4 голосов
/ 06 января 2011

Для одного вы можете тянуть в любое время; Pulling просто добавляет наборы изменений в репозиторий, но не меняет локальные рабочие файлы (кроме случаев, когда вы включили обновление после выгрузки).

Объединение необходимо, если кто-то еще внес изменения в ту же ветку, над которой вы сейчас работаете. Это создало неявную ветвь, и слияние просто объединяет их. Это хорошо видно на «железнодорожном пути» в представлении хранилища. По сути, до тех пор, пока вы не объединяетесь, вы остаетесь на своей собственной «частной» дорожке, и когда вы хотите добавить свои изменения (может быть любым количеством наборов изменений), вы сливаете их обратно в целевую ветвь (обычно «по умолчанию») ). Это безболезненно - ничего подобного слиянию в старых версиях SVN!

Так что рабочий процесс не такой жесткий, как вы его отображали; это больше похоже на это:

  • Потяните столько, сколько хотите
  • Вносить изменения и фиксировать локально так часто, как вам нравится
  • Когда ваши изменения должны быть интегрированы, объединитесь с целевой веткой (может быть ревизия ниже, чем самая новая), подтвердите и нажмите

Этот рабочий процесс может быть несколько настроен, например, с помощью именованных ветвей, а иногда и с помощью rebase. Тем не менее, вы и ваша команда должны решить, какой рабочий процесс будет использоваться; Mercurial довольно гибок в этом отношении.

2 голосов
/ 06 января 2011

http://hginit.com имеет хороший учебник.

В частности, вы найдете здесь список шагов: http://hginit.com/02.html (внизу страницы)

Разница между этими и вашими шагами заключается в том, что вы должны выполнять фиксацию после шага 1. Фактически вы обычно фиксируете несколько раз в своем локальном репозитории, прежде чем перейти к шагу вытягивания / слияния / проталкивания.Вам не нужно сразу делиться каждым коммитом с остальными разработчиками.Часто имеет смысл сделать несколько связанных изменений, а затем подтолкнуть все это.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...