Решение для медленной разницы в (черепаха) SVN? - PullRequest
Новая
       8

Решение для медленной разницы в (черепаха) SVN?

4 голосов
/ 18 марта 2010

Я часто проверяю код следующим образом:

  1. Открыть журнал SVN
  2. Выберите редакцию
  3. Двойной щелчок по файлу ...
  4. ... и ждать
  5. Посмотреть изменения
  6. Перейти к 2 или 3 или закончить

4-й шаг очень раздражает. Знаете ли вы решение для этого?

Ответы [ 6 ]

2 голосов
/ 18 марта 2010

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

1 голос
/ 18 марта 2010

Интересно отметить, возможно, что это одна из причин, по которой git хранит всю историю локально.Я сомневаюсь, что переключение на другую систему управления версиями возможно для вашего проекта, но я подумал, что должен упомянуть, что эта функция позволяет вам выполнять сравнения различий намного быстрее.

0 голосов
/ 13 апреля 2010
0 голосов
/ 13 апреля 2010

Судя по различным ответам и комментариям, ваша основная проблема заключается в задержке / пропускной способности централизованного сервера. Вот пара предложений, которые я предлагаю:

  • Ваш сервер обслуживается через http / https или более svnserve / SSH + Svnserve. По моему опыту на пред 1.5 SVN, способ svnserve был намного быстрее, чем способ http / https для поиск в разных файлах. Если я правильно напомнить мое расследование в время, когда сервировка http использует протокол, который требует туда и обратно сервер для каждого сравнения, в то время как svnserve может отправлять несколько сообщений Отличается за один раз.
  • Может ли ваш клиент одновременно запросить несколько различий? (Более конкретно, я думаю о представлении синхронизации затмений, которое может запрашивать все различия для дерева, а затем позволяет просматривать файлы без дальнейших циклических проверок.
  • Последнее направление исследований, которое я предлагаю, - это создание кеша только для чтения на вашем локальном компьютере. Есть несколько способов сделать это, которые были исследованы в: Как синхронизировать два репозитория Subversion?
0 голосов
/ 13 апреля 2010

Проблема была на нашем сервере. Я не совсем понимаю, но наш администратор сказал что-то о модуле в apache, который через PAM и SQL авторизовал пользователей. После некоторых изменений он работает достаточно хорошо.

0 голосов
/ 18 марта 2010

Несколько вопросов, которые могут помочь вам выяснить, что не так:

  • Как долго ждать 4. шаг? Что происходит на экране, пока вы ждете?
  • каков ваш пинг и пропускная способность для сервера?
  • Какую утилиту diff вы используете?
  • Каков размер файлов, которые вы различаете?
  • Сколько лет ревизия, которую вы используете?

Мои результаты:

  • шаг 4. занимает около 10 секунд, большая часть которых ожидает передачи файла (я вижу индикатор выполнения передачи файла).
  • мой пинг до сервера 20, пропускная способность ок. 2 Мбит / с
  • Я использую WinMerge. Я помню с некоторыми другими утилитами (например, DiffMerge) сравнение было очень медленным
  • файл, с которым я тестирую, - 23 000 строк / 725 КБ.
  • это с последней ревизией перед головой. В старых версиях шаг 4 может занять больше времени.

Если шаг 4 занимает у вас около 10 секунд, то я бы сказал, что в вашей настройке нет ничего плохого, и вам придется либо смириться с этим, либо начать использовать какое-то более распределенное решение, поскольку пинг 80 мс довольно много (например, Европа - США), и вы определенно почувствуете задержку. Альтернативой полностью распределенной системе может быть использование репликации сервера SVN и наличие реплицированного сервера где-нибудь ближе к вашей рабочей станции (в той же комнате, в той же стране или, если это невозможно, по крайней мере, на том же континенте, вероятно, поможет). .

...