Что такое хороший пример использования Mercurial для этой установки?

Question

У нас есть два разработчика в одной закрытой (тьфу, тупица) сети, еще один разработчик в паре минут езды по дороге и четвертый разработчик на полпути по всей стране. Электронная почта, ftp и носители для удаления - все возможные способы передачи для людей, не находящихся в одной сети.

Я один из двух разработчиков закрытых сетей, считайте нас "главным" местом.

Какова наилучшая настройка / шаблон Mercurial для группы? Каков наилучший способ передачи изменений удаленным разработчикам? Поскольку я отвечаю, я решил, что мне нужно будет сохранить хотя бы одно мастер-репо с другим локальным репо, в котором я могу развиваться. Другому человеку просто нужен клон мастера. Это правильно? Я думаю, это также делает меня ответственным за слияние?

Как видите, я все еще пытаюсь обернуть голову вокруг распределенного контроля версий. Я не думаю, что есть какой-то другой способ сделать это с ситуацией со связью.

Answer 1

Патчи - это простое и универсальное решение.

Для перемещения по большим группам изменений (особенно двоичных изменений и слияний) Mercurial предлагает двоичные пакеты. Пакет - это в основном двоичный материал, который отправляется по сети, когда вы делаете hg push, но здесь он записывается в файл.

Давайте представим, что я каким-то образом получил клон (с помощью флешки, DVD и т. Д.). Назовите это upstream. Затем я делаю второй клон, называю это devel. Я делаю все свои разработки в devel и делаю много коммитов, слияний и т. Д. Поскольку Mercurial распространяется, я могу делать все это в автономном режиме.

Чтобы увидеть, какие наборы изменений отсутствуют в upstream Я делаю

% hg outgoing ../upstream

Когда мне есть что отправить, я могу использовать

% hg bundle changes.hg ../upstream

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

Получатель пакета может сделать

% hg incoming changes.hg

чтобы увидеть список изменений и

% hg pull changes.hg

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

Обратите внимание, что репозиторий upstream используется только как удобный способ запомнить, какие наборы изменений уже найдены в вышестоящем репозитории. Вы также можете просто записать ID набора изменений и использовать hg bundle --base при связывании, чтобы указать базовый (общий) набор изменений. Смотрите hg help bundle или смотрите в вики .

Answer 2

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

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

Это мои единственные предложения - ну, очевидно, подключите их к VPN! Я хотел бы услышать, как идут дела, какие планы стабилизируются в еженедельную канавку и так далее.

Answer 3

Правильно. Единственный способ что-либо сделать это в закрытую сеть через флешку.