Использование Mercurial (hg) для отслеживания изменений и автоматической синхронизации? - PullRequest
0 голосов
/ 19 мая 2011

Прежде всего, я смотрел на страницу за страницей решений, но ни одно из них, похоже, не подходит к ситуации, в которой я находился.

У меня есть веб-разработчики по всей стране, использующие рабочие станции Windows с Eclipse.Мы решили, что DVCS лучше для нас, потому что централизованная система просто не работает (Серена: медленные сетевые подключения требуют вечности, чтобы зарегистрироваться ... они этого не делают, потому что это не "упрощено" и т. Д.)

Мы используем Eclipse для редактирования и изменения файлов на сервере разработки в другом состоянии.(В большинстве сценариев DVCS предполагается, что на вашей рабочей станции настроен веб-сервер или вы выполняете бинарный исполняемый файл.)

Я хотел бы попробовать создать локальный репозиторий для изменений разработчика и "воспроизведения функций", ноавтоматически обновлять репозиторий разработки.Я думал об использовании перехватчиков Mercurial для автоматического извлечения / обновления / слияния / переноса, но это требует от разработчика коммитов каждый раз, когда они хотят протестировать изменения.(Для того, чтобы запустить их, чтобы загрузить их файл на сервер разработки.) Было бы идеально, чтобы это автоматически происходило при сохранении файлов, потому что это уже проблема с обучением людей использовать контроль версий (в основном потому, что в настоящее время PITA работает медленно сWAN и виртуальные местоположения. Обновление WAN не вариант.)

Я предполагаю, что мне придется настроить Unison или что-то другое, чтобы синхронизировать репозиторий разработчика с сервером разработки, как если бы это былолокальная копия и, конечно, будет синхронизироваться с другими разработчиками.Я пытался выяснить, есть ли у кого-нибудь оптимизированное / простое решение, позволяющее поддерживать всех разработчиков в курсе, позволяя им управлять версиями по желанию (легко.)

Ответы [ 3 ]

0 голосов
/ 20 мая 2011

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

Я управляю своими развертываниями таким образом.Веб-корневой каталог виртуального хоста моего веб-сервера указывает на хранилище / рабочую копию Mercurial.Когда что-то готово к выходу, я объединяю это в «стабильную» ветку и помещаю «стабильную» на сервер.Хук репозитория обновляет файлы на виртуальном хосте новыми изменениями.

[hooks]
changegroup = /usr/bin/hg update stable >&2

Я делал это только месяц или около того, но он работал как чудо.

Также +1 при проверке Хадсон / Дженкинс.То, что вы ищете, называется «непрерывной интеграцией» (CI), и Хадсон и Дженкинс делают это.

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

0 голосов
/ 20 мая 2011

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

Ваша лучшая ставка вэтот сценарий, вероятно, будет выполнять ветвление на сервере разработки и иметь на сервере различные ветви для проверки различных функций (hg update -C feature-blah).Состояние по умолчанию для репозитория сервера должно быть извлечением основной ветки "devel" (hg update -C devel), и когда какие-либо функции или ветки с исправлениями проверяются как работающие, они объединяются обратно в "devel", а хранилище сервера обновляется.Исходя из этого.

Отредактируйте, чтобы уточнить: ваши разработчики будут извлекать из "devel" или из ветви функций на свою локальную машину.Затем они вносят любые изменения и отправляют их обратно на сервер, а затем переключают активную ветвь сервера на недавно обновленный код.

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

0 голосов
/ 20 мая 2011

Мы очень довольны Mercurial, но нам пришлось изменить свои привычки ... и это заняло некоторое время

У каждого разработчика теперь есть тестовая платформа локально.Коммиты делаются через ветки, и ничего не передается, пока тесты не были проверены локально

Тогда Хадсон - наш друг.Для интеграции групповых работ каждая фиксация приводит к сборке, которая проверяет целостность приложения.Красный цвет означает откат и возврат к разработчику.Зелёный - это круто

Разработчики здесь для того, чтобы фиксировать «нормальный» код и интегрироваться командой в центральное хранилище.Они должны решить, когда пора подтолкнуть.Никакая синхронизированная задача не может избавить их от этого бремени.Когда я вижу все ошибки, которые могут произойти, даже если человек делает добросовестный выбор, я не могу себе представить, произошли ли автоматически изменения в каждом файле, кроме

Хороший опыт работы с Mercurial ...

...