Как использовать репликацию в сочетании с системой контроля версий?

Question

Ситуация следующая:

Наша компания работает на двух основных производственных площадках, общаясь через WAN . Мы разрабатываем программное обеспечение для внутреннего использования, которое использует около 100 ГБ дискового пространства на наших серверах (данные приложений развертываются для наших клиентов с большим количеством изображений). Для повышения производительности наши сетевые администраторы выбрали репликацию DFS (каждые 6 часов). Это означает, что нашим пользователям (сотрудникам компании) не нужно ждать (иногда 2-3 часа), чтобы загрузить необходимые файлы, поскольку они доступны локально (по локальной сети).

Проблема в том, что алгоритм, используемый репликацией DFS, "Last Writer Wins" . Таким образом, в случае одновременных изменений (во время разработки / сопровождения), файл с самой последней датой победит. Я хотел бы избежать такой потери данных .

Я менеджер проекта по общему процессу разработки. Я хочу познакомить людей с системами контроля версий, чтобы решить проблему одновременных модификаций. Я планирую использовать Mercurial по нескольким причинам, главным образом потому, что он распространяется, прост в объяснении, может использоваться для личного использования, бесплатен и (что наиболее важно) обладает отличными возможностями слияния . Однако преимущества системы контроля версий при локальном использовании (LAN) теряются из-за процесса репликации (WAN), который не знает, как объединить.

Некоторые возможные решения:

1. использовать только управление версиями через WAN (надеясь, что сжатия будет достаточно, чтобы ускорить процесс)

2. использовать только DFS и отслеживать изменения вручную (подвержены ошибкам) ​​

3. найти обходной путь обоими методами

Команда мала (около 10 человек). Ваша помощь и опыт приветствуются.

Answer 1

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

Репо каждой команды следует регулярно синхронизировать(например, ежедневно, в вашем 6-часовом расписании или даже чаще) с репо из другого местоположения, чтобы отразить изменения, сделанные в этой ветке.Затем они будут объединены с веткой сайта (в идеале это будет сделано автоматически в рамках одного и того же обновления, но точные детали того, как произойдет это объединение, могут отличаться, в зависимости от выбранной вами VCS и модели ветвления).*

Помните: "рано синхронизировать, часто синхронизировать"