У нас есть два разработчика в одной закрытой (тьфу, тупой правительственной) сети, еще один разработчик в паре минут езды по дороге и четвертый разработчик на полпути по всей стране. Электронная почта, ftp и носители для удаления - все возможные способы передачи для людей, не находящихся в одной сети.
Я один из двух разработчиков закрытых сетей, считаю нас «хозяином» локации.
Какова лучшая настройка / шаблон Mercurial для группы? Каков наилучший способ передачи изменений удаленным разработчикам? Поскольку я отвечаю за это, я решил, что мне придется сохранить хотя бы одно мастер-репо с другим локальным репо, в котором я могу развиваться. Другому человеку просто нужен клон мастера. Это правильно? Я думаю, это также делает меня ответственным за слияние?
Как вы можете видеть, я все еще пытаюсь обернуть голову вокруг распределенного контроля версий. Я не думаю, что есть какой-то другой способ сделать это с ситуацией со связью.
Пользователи за пределами сети могут вносить исправления и / или использовать электронную почту для отправки обновлений в основной репозиторий или кому-либо, как вам, чтобы объединить их. Другие внутренние сотрудники могут иметь локальные копии, такие как вы, и выполнять слияния, но если у вас их нет в сетевых исправлениях, может быть лучше, чтобы один человек имел с ними дело, чтобы никто не запутался, но это то, что вам придется считать себя
Синхронизируя другой способ, вы создадите патч и отправите им электронное письмо или получите флэш-накопитель для удаленных разработчиков, чтобы установить патч для своей системы. Тебе понадобится хорошее общение в команде, я благодарен, что я не на твоем месте.
Это мои единственные предложения - хорошо, очевидно, получить им VPN-соединение! Я хотел бы услышать, как идут дела, какие планы стабилизируются в еженедельную канавку и так далее.
Верный. Единственный способ что-либо сделать это в закрытую сеть через флешку.
Патчи - это простое и универсальное решение.
Для перемещения больших групп изменений (особенно бинарных изменений и слияний) 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или смотрите в вики .