У нас проблема с SVN ... Клиенты Subversion, такие как TortoiseSVN, зависают, когда мы фиксируем на нашем сервере более нескольких файлов за раз. Кажется, что все на самом деле успешно зафиксировано в репозитории; но клиент зависает после того, как все данные были переданы.
Мы используем версию 1.4.4 сервера SVN. Для подключения мы используем протокол svn: //, а не http.
Мы воспроизвели эту проблему с несколькими клиентами: TortoiseSVN (1.6.10), AnkhSVN (2.1) и клиентом командной строки Silk (1.6.12). Это происходит со всеми в команде, хотя некоторые люди, кажется, страдают больше, чем другие. Если кто-то фиксирует только несколько файлов, это часто срабатывает; но с более чем полдюжиной файлов обычно зависает.
Есть ли у кого-нибудь предложения по устранению неполадок? Некоторое время это происходило спорадически, но в последнее время стало довольно стабильно. Мы работали над проблемой, убивая зависшего клиента SVN, выполняя «svn cleanup», а затем выполняя «svn up»; но иногда это вызывает конфликты деревьев. Другой обходной путь - убирать рабочую область и проверять ее снова после каждой фиксации; но, конечно, это очень раздражает.
Есть ли какие-либо средства диагностики, которые могут помочь нам устранить эту проблему? Мы рассматриваем возможность обновления до сервера SVN 1.6 и установки сервера на новом компьютере; но нам интересно, есть ли более простое решение.
Спасибо за вашу помощь,
Ричард
Можешь попробовать strace svn daemon, когда возникает проблема, чтобы посмотреть, что там происходит.
Svn очень плохо работает с файловыми системами, особенно с NTFS, потому что файловая система медленнее обращается ко многим маленьким файлам ....
Попробуйте переместить свою рабочую копию на внешний жесткий диск, отформатированный в FAT 32 / FAT 16, или использовать ее из linux (ext3), но не ожидайте, что это будет слишком быстро (это также архитектура svn, которая плохая с его слишком большим количеством ". svn "файлы)
Еще одна вещь, которую я сделал, чтобы избежать этих проблем, - это выбрать только измененные файлы вместо всей базовой рабочей копии перед фиксацией.
В любом случае, у меня была такая же проблема в течение многих лет ... Теперь я обнаружил Git, который был разработан Линусом Торварльдом с учетом файловых систем и скорости, я рекомендую вам попробовать его еще и потому, что github потрясающий и изучение его дает много возможностей для разработчик.