git repo как промежуточное звено между двумя репозиториями SVN для синхронизации - PullRequest
Новая
       53

git repo как промежуточное звено между двумя репозиториями SVN для синхронизации

0 голосов
/ 18 декабря 2018

Я не совсем хорош в мышлении GIT - и чувствую себя потерянным в сценарии, о котором я думаю.

Короче говоря, я пытаюсь использовать промежуточное локальное репозиторий Git для синхронизации двух отдельных репозиториев SVN на разных машинах / в сетях.Меня не волнуют коммиты на второй репо - я хочу, чтобы он был просто зеркалом первого репо.По сути, я запрещаю коммиты на второй репо, поэтому не должно быть никаких конфликтов.Итак, как мне это сделать?

Мне удалось клонировать существующее репозиторий SVN (git svn clone ..), но как мне указать это другое зеркальное репо в качестве второго удаленного пульта?

Люди говорят об изменении файла .git / clone напрямую для добавления второго "удаленного" - но затем они как бы подключают его к новой ветви - я не совсем хочу этого делать,Я просто хочу перенести изменения, которые я получаю, из моего основного репозитория SVN во второй пульт SVN.

По сути, git svn fetch из репозитория SVN 1 и git svn dcommit НЕ в репозиторий SVN 1, а в репозиторий SVN 2.

Я понимаю, что какое-то отслеживание для второго репо должно бытьвключен.О, черт возьми, это кажется возможным, но я просто не могу понять это.Помогите кому-нибудь?Спасибо.

Причина, по которой я был озадачен при взгляде на решение svnsync, заключается в том, что в один момент времени два репозитория SVN изолированы.Сначала мне нужно VPN до первого репо, получить изменения, отключиться, затем подключиться через VPN2 ко второму репо и нажать.Вот почему Git промежуточного локального репо обратился ко мне .. Там есть это , но опять же, я вроде как нахожу это сложным.Нет ли более простых решений?Ну что ж ... я должен рассматривать промежуточное репо SVN или репо SVK как более естественные решения?Еще раз спасибо.

1 Ответ

0 голосов
/ 02 января 2019

Поскольку у нас нет требования

  • , чтобы номера ревизий оставались одинаковыми в обоих репозиториях
  • отслеживание изменений также в репозитории DESTINATION (DESTINATION доступен только для чтения.клиенты)

Решение, предложенное AH, кажется самым простым и наиболее практичным.Учитывая, что

  • SOURCE_REPO, например, svn: // XXXX / some_repo
  • DESTINATION_REPO, например, file: /// C: / some_other_repo

Для выгрузкисодержимое существующего репозитория (вся история - медленно для больших репозиториев): 

svnrdump dump SOURCE_REPO > repo.dmp

Чтобы вывести только текущую ревизию: 

svnrdump dump -rHEAD SOURCE_REPO > repo.dmp

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

Чтобы импортировать этот файл дампа в другой репозиторий (работает с http/ svn тоже?) 

svnrdump load DESTINATION_REPO < repo.dmp

обратите внимание, что при экспорте и импорте REVISION NUMBERS не синхронизируются.- при экспорте они не сохраняются в файл дампа, а при импорте каждая ревизия сохраняется как увеличенное число - поэтому, если мы сбросили только ревизию HEAD исходного репозитория и импортируем в первый раз, она будет сохранена как ревизия1 в хранилище DESTINATION

...