Какая хорошая модель использования Mercurial для этой настройки?
У нас есть два разработчика в одной закрытой (тьфу, глупые gov) сети, еще один разработчик пару минут проезжает по дороге, а четвертый разработчик на полпути по всей стране. E-Mail, ftp и средства удаления - все возможные способы передачи для людей, не входящих в одну сеть.
Я один из двух закрытых сетевых разработчиков, считаю нас "хозяином".
Какая лучшая настройка/шаблон Mercurial для группы? Каков наилучший способ перевести изменения в/от удаленных разработчиков? Поскольку я отвечаю за это, я решил, что мне придется держать по крайней мере одно основное репо с другим местным репо, в котором я могу развиваться. Каждому другому человеку нужно просто клонировать мастера. Это правильно? Думаю, это также заставляет меня отвечать за слияние?
Как вы можете видеть, я все еще пытаюсь обернуть голову вокруг распределенного контроля версий. Я не думаю, что есть другие способы сделать это с ситуацией подключения.
Ответы
Ответ 1
Пользователи вне сети могут сделать патчи и/или использовать email, чтобы отправлять обновления основному репо или кому-то, например, самому себе, чтобы объединить их. Другие внутренние люди могут иметь локальные копии, например, вы сами и сливаются, - но если у вас есть эти сетевые патчи, может быть, лучше, чтобы один человек имел дело с ними, поэтому никто не путается, но что-то, что вам нужно считайте себя.
Синхронизируя другим способом, вы должны создать патч, и они отправят электронную почту или получат флеш-диск для удаленных разработчиков, чтобы исправить их систему. Вам понадобится хорошее общение в команде, я благодарен, что я не в ваших силах.
Это мои единственные предложения - ну, очевидно, получите им VPN-соединение! Мне бы хотелось услышать, как это происходит, какие планы стабилизируются в еженедельный паз и т.д.
Ответ 2
Патчи - это простое и универсальное решение.
Для перемещения больших групп изменений (особенно двоичных изменений и слияний) 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 используется только как удобный способ запомнить, какие изменения уже найдены в восходящем репозитории. Вы также можете просто записать идентификатор набора изменений и использовать hg bundle --base при наборе, чтобы указать базовый (общий) набор изменений. См. hg help bundle или посмотреть в вики.
Ответ 3
Правильно. Единственный способ сделать это на закрытой сети - с помощью флеш-накопителя.
