TFS проверяет время ожидания набора изменений, содержащего "большие" двоичные файлы

Question

Я выполняю миграцию TFS Integration с tfs.visualstudio на локальный сервер 2012 года. Я столкнулся с проблемой с конкретным набором изменений, который содержит несколько двоичных файлов, превышающих 1 МБ, некоторые из которых имеют размер 15-16 МБ. [Я работаю удаленно (WAN) с локальной TFS]

Из журналов TFSI я вижу: Microsoft.TeamFoundation.VersionControl.Client.VersionControlException: C:\TfsIPData\42\******\Foo.msi: The request was aborted: The request was canceled. ---> System.Net.WebException: The request was aborted: The request was canceled. ---> System.IO.IOException: Cannot close stream until all bytes are written.

Делая некоторые поиски, я столкнулся с другими, сталкивающимися с подобными проблемами, не обязательно касающимися интеграции TFS. Я уверен, что такая же проблема возникнет, если я просто проверю изменения, как обычно, которые соответствуют тем же критериям. Насколько я понимаю, при загрузке файлов (регистрации) размер порции по умолчанию составляет 16 МБ, а время ожидания - 5 минут.

Моя скорость загрузки интернета на этом сайте составляет всего 1 Мбит / с. (Хотя я думаю, что проблема будет уменьшена с достаточной пропускной способностью загрузки, это не решит проблему).

Используя TCPView, я наблюдал за подключениями к серверу TFS от моего клиента во время загрузки. Я вижу 9 одновременных подключений. Таким образом, моя пропускная способность распределяется между 9 загрузками файлов. Конечно, примерно через 5 минут соединения прерываются до того, как закончится число загружаемых байтов.

У меня вопрос, как я могу настроить свой клиент TFS для использования меньшего количества одновременных соединений, и / или меньшего размера чанка, и / или увеличенного времени ожидания? Можно ли это сделать где-нибудь глобально, чтобы охватить VS, TF.EXE и интеграцию TFS?

Answer 1

Проведя некоторое время с IL DASM, ковыряясь в Microsoft.TeamFoundation.VersionControl.Client.dll FileUploader, я обнаружил в конструкторе строку VersionControl.UploadChunkSize, Похоже, он используется для переопределения размера чанка по умолчанию (DefaultUploadChunkSize = 0x01000000).

Итак, я добавил это в TfsMigrationShell.exe.config

<appSettings>
    <add key="VersionControl.UploadChunkSize" value="2097152" /> 
</appSettings>

и снова запустил миграцию VC - на этот раз он преодолел проблему changeset!

В основном клиентская DLL TFS будет пытаться загрузить несколько файлов одновременно (9 в моем случае). Пропускная способность вашей загрузки будет распределена между файлами, и если какая-либо отдельная передача файла не может завершиться 16 МБ за 5 минут, операция не будет выполнена. Таким образом, вы можете видеть, что при скромной пропускной способности загрузки наборы изменений, содержащие несколько двоичных файлов, могут истечь. Единственное, что вы можете контролировать, это байтовый счет каждого 5-минутного блока тайм-аута. Значение по умолчанию составляет 16 МБ, но вы можете уменьшить его. Я уменьшил мой до 2 МБ.

Я полагаю, что это может быть сделано для devenv.exe.config для решения той же проблемы при выполнении проверки кода разработчика. Надеемся, что эта информация поможет кому-то еще и сэкономит им время.