Как получить репликацию master-master с помощью Subversion?

Кажется, простая проблема:

  • У меня есть SVN-репо внутри нашего брандмауэра.
  • У меня есть SVN-репо вне нашего брандмауэра.
  • У меня есть пользователи внутри и снаружи брандмауэра. (VPN не является опцией:( это было бы слишком легко)
  • машины внутри брандмауэра МОЖЕТ говорить с внешним сервером SVN. Но не так.
  • внешний SVN - это временная вещь - основное репо всегда будет внутри.

Я хочу как-то (изнутри, скорее всего) принять все изменения в одном и применить их к другому. И наоборот. Звучит просто, и я предполагаю, что подобные GIT могут это сделать, но мы используем SVN.

Кто-нибудь это сделал? Я не возражаю, что это ручная процедура - есть только пара внешних людей, и они не нуждаются в обновлениях в минуту, два или три раза в день.

Я считаю, что apache.org делает это, но я не могу найти документы о том, КАК они это делают. Есть несколько продуктов, которые делают это (ну, один), но я хотел бы знать, есть ли у кого-то хороший, чистый способ сделать это без них. svnsync делает это, только в одном направлении (master-slave)

Счастлив, чтобы он работал на Windows, Linux или Mac, так как у нас есть все. Windows и Mac предпочли хотя.

Помощь!:):)

[обновление] после 12 месяцев беспорядков (и не нуждающихся в этом в конце), правильный ответ, на мой взгляд, правильный. Используйте GIT - у вас есть одно репо, которое вытаскивает из SVN-A, затем нажимаем на новый репозиторий GIT, а затем отталкиваемся от него к SVN-B. Должен работать:)

ОТВЕТЫ

Ответ 1

Я бы рекомендовал SVK или git-svn.

Оба из них позволяют создавать внешнее зеркало вашего репозитория svn и позволяют внешним разработчикам совершать транзакции непосредственно во внешнем зеркале. Затем вы можете вытащить и направить изменения с этого внешнего зеркала на внутреннее основное репо.

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

SVK, однако, позволяет внешним разработчикам продолжать использовать svn. Поскольку внутреннее репо доступно только внутренне, внутренняя учетная запись или пользователь должны будут обрабатывать периодическую синхронизацию (возможно, работа cron будет работать).

Здесь расширенное руководство по вики SVK: UsingSVKAsARepositoryMirroringSystem

Ответ 2

Простота - это, как правило, лучший способ, и похоже, что у вас уже есть простое решение: используйте репозиторий SVN вне брандмауэра.

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

Сообщите мне, если мне не хватает части ваших требований.

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

Ответ 3

Одной из особенностей Enterprise Edition для VisualSVN Server является репликация многопользовательского репозитория, которая делает именно то, что вы ищете.

Эта функция основана на технологии распределенной файловой системы VisualSVN (VDFS), которая была разработана для обеспечения прозрачной репликации репозитория Subversion на географически распределенных сайтах. Некоторые из примечательных особенностей VDFS:

  • Все распределенные репозитории VDFS Subversion доступны для записи,
  • VDFS обеспечивает прозрачную двунаправленную репликацию данных,
  • VDFS поддерживает правила авторизации репликации и расширенные механизмы аутентификации, такие как встроенная проверка подлинности Windows (NTLM/Negotiate) с защищенным SSL/TLS-шифрованием.
  • Все репозитории VDFS содержат один и тот же набор данных,
  • Репликация репозитория через WAN с VDFS до x10 быстрее, чем репликация на основе прокси-сервера прокси,
  • Конфигурация VDFS выполняется через графический интерфейс без каких-либо сложных шагов.

Стоит отметить, что VDFS следует классической модели репликации master-slave, которая имеет значительные преимущества по сравнению с моделью репликации master-master, поскольку она более подходит для репликации репозиториев Subversion с использованием бэкэнда типа FSFS. Технология VDFS гораздо более надежна, чем решения репликации master-master для SVN.

VDFS configuration interface for multisite Apache SVN repos

Ответ 4

Хм... я считаю, что сохранение двух репозиториев синхронно друг с другом является нетривиальным. Это включало бы в основном преобразование SVN в Mercurial или Git.

Ответ 6

Одна вещь, которую вы могли бы попробовать, - это реплицировать репо на уровне файла. Я использую FolderShare (http://www.foldershare.com - работает в Windows и Mac) для аналогичного сценария, хотя я реплицирую его только для целей резервного копирования и не пытались подключиться с помощью SVN к реплике.

Ответ 7

http://wandisco.com/subversion/multisite/

Использование Subversion MultiSite Уникальная репликация WANdisco технологии для немедленной синхронизации Хранилища Subversion, связанные глобальной сети (WAN). Пользователи в каждый локальный опыт скорость сети (LAN) для как операции чтения, так и записи. Subversion MultiSite также обеспечивает непрерывное горячее резервное копирование и самовосстановление возможности, которые автоматизируют катастрофу восстановления, так что время простоя практически устранены.