Как можно синхронизировать два SVN репозитория одинаковых проектов?

Доброго времени суток!

Ситуация следующая: есть два офиса, расположенных в разных городах. Программисты обоих офисов работают над одним и тем же большим проектом (над разными его частями). У обоих есть локальные SVN-репозитории. По определенным причинам, иначе поступить нельзя, SVN-репозиторий должен быть у каждого свой (с каждого офиса есть возможность подключения по rdp к машинам другого офиса). Проблема в следующем: каждые 1-2 недели приходиться ездить в другой город (благо расположен недалеко) и сливать свои изменения в их репозиторий, а их в наш. Можно ли как-нибудь этот процесс автоматизировать? Без поездок в другой город :)
  • Вопрос задан
  • 2967 просмотров
Решения вопроса 1
Vapaamies
@Vapaamies
Психанул и снес свои ответы козлам, не отмечающим…
Я вижу два решения.

Первый вариант -- завести мета-репозитарий, в котором ссылки на обе части хранятся в свойстве svn:external. При каждом обновлении из мета-репозитария он будет делать вложенный запрос на обновление соответствующей части. Фиксировать изменения, естественно, придется в репозитарий своей части, а качать обновления для сборки -- из мета-репозитария.

Этот способ требует онлайн-доступности обоих частей, иначе обновление по svn:external будет зависать до истечения таймаута.

Вторым способом хотел порекомендовать использовать svnsync, но так и не понял из справки, можно ли сделать частичное зеркалирование. Сам использую только полное зеркалирование, так что точнее не подскажу.

Если же частичное зеркалирование невозможно или работает не так, как вам хочется, при помощи svnsync можно расширить первый способ: в обоих филиалах завести полное зеркало и svn:external натравить уже на него. Тогда онлайн-доступность не потребуется, можно будет синхронизироваться как удобно. Издержки с "пишем в одно место" -- "качаем для сборки из другого" останутся.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
index0h
@index0h
PHP, Golang. https://github.com/index0h
Ну, раз не целевое использование централизованной VCS, как распределенной оправдано...

Что вам мешает сливать последние правки из удаленного на локальную машину -> намердживать в свой репозиторий -> сливать последнее состояние файлов обратно -> делать коммит?

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

Лучше убедите руководство, что жрать кактус - это плохо (первая строка моего ответа). Либо используйте централизированные vcs по их назначению, либо - децентрализированные.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы