TortoiseSVN 1.7 чрезвычайно медленно выполняет коммит и проверяет изменения в общем сетевом ресурсе

Question

Эта проблема относится только к операциям с TortoiseSVN 1.7 и только к сетевому ресурсу.

На сервере dev у меня есть рабочая копия svn, где я могу что-то зафиксировать и затем обновить на рабочем сервере.
Иногда, когда все активные сеансы на сервере dev заняты (я не могу подключиться по RDP), я делаю «Commit» по сетевому ресурсу с другого сервера dev.
Итак, я открываю DEV-2, затем открываю сетевой каталог:\\ DEV \ Project и нажмите «Подтвердить» или «Проверить изменение».
В этот момент диалог открывается очень медленно (30-40 минут).Нет версионных файлов.И неважно, сколько измененных файлов (может быть 0).

Примечание: операция «Обновление» работает нормально.
Также вышеописанные проблемы работают хорошо со старыми версиями TortoiseSVN (например, 1.6).

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

Может быть, кто-то знает, как обойти эту проблему?Или, может быть, есть какая-то настройка, которую можно отключить?

Я нашел такой же вопрос на форуме разработчиков черепах.Но также без решения: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2892466

---

Обновление 1:
Я добавил аналогичный вопрос на форуме разработчиков черепах:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909472

Answer 1

Оригинальный постер в более позднем посте в ветке tigris.org, на который вы ссылались, гласит:

"Я нашел решение. Если я деактивирую

Настройки-> Общие -> Диалоги 2-> Статус -> "Вернуть в неверсионные папки"

все работает как и раньше с TortoiseSVN v1.6.x. "

http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2893160

Answer 2

Используете ли вы протокол file://? Если да, остановите это сейчас - особенно в сетевой папке.

Никогда не следует использовать file:// в хранилище Subversion, особенно если его используют несколько пользователей.

Это особенно верно, поскольку очень легко получить и запустить svnserver, облегченный серверный процесс Subversion. Есть даже указания, как заставить это работать как Windows Service .

Единственная проблема заключается в том, что ваш сайт блокирует порт 3690 в вашей сети. Тем не менее, это должно быть довольно легко исправить. Если нет, вы можете получить один из многих бесплатных пакетов Apache HTTPD / Subversion от VisualSVN, Wandisco и даже CollabeNet, которые позволяют легко настроить сервер Subversion с использованием HTTPD в системе Windows.

Единственная другая возможная проблема заключается в том, что вы используете старый рабочий каталог Subversion 1.6 с TortoiseSVN 1.7. Макет рабочего каталога для Subversion 1.7 изменился, и вы действительно должны сделать новую чистую проверку.

Answer 3

В качестве обходного пути мы превратили Show Locks

Щелкните правой кнопкой мыши папку и выберите Tortoise\Settings, затем General\Dialog 3, затем , отмените выбор Show Locks

Пожалуйста, посмотрите на http://tigris -scm.10930.n7.nabble.com / Обходной путь для медленного репозиторияBrowser-on-large-repositories-td92324.html тоже

Answer 4

На мой взгляд, лучшим "обходным путем" для этой "проблемы" было бы попросить ваших администраторов улучшить инфраструктуру вашего проекта.Предполагается, что SVN поможет вам синхронизировать локальную копию некоторого дерева исходного кода с удаленным оригиналом.Если вы вынуждены войти в некий -remote- «dev-сервер» со своего локального компьютера и зафиксировать изменения в сетевом каталоге --remote--, тогда существуют некоторые ограничения, которые не позволяют работать в наиболее оптимальном (приемлемом) режиме.путь.Я, вероятно, могу понять, почему это происходит, если клиент не позволяет вам получить копию кода на вашем локальном компьютере, но заставлять людей работать через RDP абсолютно безумно.Не работай на людей с такими глупыми требованиями.Работодатель должен, по крайней мере, способствовать тому, чтобы вы приходили и работали на «dev-сервере», а не через RDP.

Менее идеалистическим предложением было бы использование двоичного файла svn из командной строки на хосте, где находятся измененные файлы (не через сетевое подключение).Вы устраняете источники ошибок, работая с инструментами напрямую.