Способы синхронизации большого количества (небольших) файлов по сетевому соединению с высокой задержкой

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

В нашем приложении много маленьких файлов (.aspx, .config и т.д.) и несколько больших файлов (.dll, .jpg) общим размером около 100-200 МБ.

В настоящее время я рассматриваю возможность сделать следующее:

  1. Сделайте локальную проверку svn на сервере
  2. Заархивируйте результат
  3. FTP или rsync большой zip-файл на чужой машине
  4. Разархивировать файл во временную папку.
  5. Выполнение локальной rsync из этой временной папки в нашу обычную папку установки.

Есть ли лучшие решения?

  • Настроить зеркало Subversion ближе к месту назначения? (Мне это понадобится всего на несколько часов в месяц, но может быть трудно найти)
  • Используете другую систему контроля версий? (Лучше ли git для соединений с высокой задержкой)?
  • Существуют ли способы упаковки исправлений Subversion (включая двоичные файлы) для повторного применения в месте назначения вместо отправки всех данных?
  • Будет ли лучше использовать DropBox (который использует Amazon S3) для передачи файлов во временную папку?

synchronization svn rsync cwrsync
person Jason Kealey    schedule 18.01.2010    source источник
comment
›› Существуют ли способы упаковки исправлений Subversion (включая двоичные файлы) для повторного применения в месте назначения вместо отправки всех данных? // Вы описываете git.   -  person jpdaigle    schedule 18.01.2010

Ответы (3)


arrow_upward
4
arrow_downward

Не отключайте rsync для всего дерева небольших файлов, пока не попробуете. Он не выполняет циклический обход для каждого отдельного файла, он конвейерный, поэтому он должен быть таким же быстрым, как и все остальное во всем наборе данных. (Настолько быстро, насколько TCP может повторно собрать кадры в упорядоченные пакеты на вашем канале с высокой задержкой.)

Ознакомьтесь с как работает rsync, чтобы узнать, как он избегает двусторонних запросов. .

person jpdaigle    schedule 18.01.2010
comment
В настоящее время я запускаю тест. Кажется, у нас есть победитель. Я предполагал, что он выполняет пофайловую передачу, но, похоже, я ошибся! - person Jason Kealey; 18.01.2010
comment
В моих тестах он работал медленнее (примерно в 10 раз), чем FTP, но не зависал, как Subversion, и ему не нужно было повторно загружать тот же контент во время следующего запуска. - person Jason Kealey; 19.01.2010

arrow_upward
2
arrow_downward

Вы можете создать патч в стиле Unix для всех изменений во всех файлах. И просто перенесите это в zip-файле.

person nholling    schedule 18.01.2010
comment
Вы должны были бы свернуть свой собственный, чтобы сделать это. Я не думаю, что Subversion делает это из коробки. - person nholling; 18.01.2010
comment
+1, хотя для двоичных файлов это не сработает. А TortoiseSVN может применять исправления к рабочим копиям. - person Michael Hackner; 18.01.2010
comment
Для меня это звучит слишком сложно, и использование TortoiseSVN в сеансе служб терминалов на удаленном конце будет жестоким, когда для регистрации каждого щелчка требуется 3 секунды. - person jpdaigle; 18.01.2010
comment
Патч также должен обрабатывать двоичные файлы. Он должен отслеживать все изменения. - person nholling; 18.01.2010

arrow_upward
0
arrow_downward

Вы можете использовать git (возможно, вместе с git-svn) для обработки передачи. Это удивительно эффективно для перемещения различий в версиях файлов.

В противном случае вы можете использовать инструмент сравнения двоичных файлов xdiff.

person Yann Ramin    schedule 18.01.2010