Подтвердить что ты не робот

Visual Studio 2013 + TFS = Slow

Я использую недавно переустановленный ноутбук с SSD. Я использую Visual Studio 2013 с TFS.

Моя проблема в том, что мне нужно ждать около 20 - 25 секунд, когда я начинаю, и когда я заканчиваю слияние или сравнение. Время ожидания завершения сеанса веб-отладки также составляет около 30 секунд.

У меня нет специальной конфигурации. Сервер TFS находится в нашей локальной сети, и я подключен через ethernet. У меня нет прокси-сервера, настроенного в настройках TFS.

Я уже пробовал следующее:

  • Удаленные файлы suo
  • Добавлена ​​настройка конфигурации приложения visual studio 2013 для отключения прокси.
  • Сохранение символов локально
  • Повторно добавленные сопоставления
  • Снова добавленное рабочее пространство

У меня нет таких проблем с проектами, которые находятся за пределами TFS. У моих коллег нет этой проблемы.

4b9b3361

Ответ 1

Существует несколько доступных вам вариантов, которые вы еще не пробовали:

Локальная рабочая область vs Рабочая область сервера

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

Рабочее пространство сервера, с другой стороны, просто просматривает бит "только для чтения". Если он имеет один, TFS будет считать его неизменным. Если он не имеет одного, TFS предполагает, что он извлечен.

Локальные рабочие области имеют свои преимущества, особенно если вы много работаете в автономном режиме, но они могут вызвать серьезное замедление в описанных выше случаях.

Попробуйте настроить рабочую область как рабочее пространство сервера, чтобы убедиться, что это устраняет проблему.

enter image description here

Visual Studio по умолчанию создает локальное рабочее пространство с момента появления этой функции.

Удалите большие двоичные файлы и соответствующим образом примените рабочее пространство

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

Чтобы скрыть файл, отредактируйте отображение рабочей области и добавьте папку, которую вы не хотите извлекать, и установите действие с "active" на "cloak", или вы можете скрывать непосредственно из контекстного меню Source Control Explorer, вы можете найти его под Advanced, затем Cloak.

Вместо того, чтобы проверять свои двоичные ссылки, попробуйте найти соответствующие пакеты NuGet или создайте их самостоятельно. Большие двоичные файлы всегда являются вредителями, когда дело доходит до систем управления версиями, поскольку вы никогда не сможете их объединить, и они просто просто сидят там.

Коррекция кэша

Клиент Team Explorer хранит кеш в следующем местоположении:

C:\Users {имя пользователя}\AppData\Local\Microsoft\Team Foundation {версия}\Cache

По какой-то причине это может быть повреждено. Очистка всех подпапок и VersionControl.config может быть последней попыткой заставить его снова работать.

Восстановить Visual Studio и отключить расширения

Иногда Visual Studio можно немного смутить всеми исправлениями, пакетами обновления и другими вещами, которые устанавливаются. Чтобы даже не упоминать все расширения, которые могут повлиять на его поведение.

Некоторые расширения могут серьезно замедлить взаимодействие с контролем источника. Ранее упомянутые расширения проводника управления версиями, например, имеют возможность изменить дату файлов на диске, что может привести к тому, что операции "Get" будут сбиты с самого конца в течение нескольких секунд.

Отключение таких расширений, чтобы убедиться, что поведение по-прежнему существует без них - это всегда то, что вы должны делать. Восстановление Visual Studio и повторное применение последнего пакета обновлений также могут помочь в решении таких проблем.

Подозрительные расширения включают те, которые:

  • Расширьте отладчик
  • Расширение Team Explorer
  • Расширьте проводник исходного кода

Отключить автоматическое обнаружение прокси-сервера Windows

Я видел какое-то поведение нечистоплотного поведения, а не во всех сетях, а не со всеми прокси-серверами, когда включена функция автоматического обнаружения Windows Proxy. Обнаружение прокси-сервера может вызвать длительные ожидания, пытаясь выяснить, к какому прокси подключиться.

Попробуйте отключить прокси-сервер script и автоматическое обнаружение, если вы зависите от прокси-сервера, попробуйте настроить его непосредственно на экране конфигурации классического прокси-сервера:

enter image description here

Постарайтесь найти проблему трудным способом

Включить трассировку на стороне клиента, как описано здесь. В devenv.exe.config включите следующий фрагмент. Он сбрасывает все, что происходит вокруг TFS, в файл журнала. Это может быть болью, чтобы точно определить, что происходит, но это даст вам массу информации:

<system.diagnostics>
  <switches>
    <add name="TeamFoundationSoapProxy" value="4" />
    <add name="VersionControl" value="4" />
  </switches>
  <trace autoflush="true" indentsize="3">
    <listeners>
      <add name="myListener" type="Microsoft.TeamFoundation.TeamFoundationTextWriterTraceListener,Microsoft.TeamFoundation.Common, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" initializeData="c:\tf.log" />
      <add name="perfListener" type="Microsoft.TeamFoundation.Client.PerfTraceListener,Microsoft.TeamFoundation.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    </listeners>
  </trace>
</system.diagnostics>

И вы можете запустить Visual Studio с ведением журнала отслеживания активности. Если плагин плохо себя ведет, он часто приводит к информации в ActivityLog.xml. Чтобы включить этот тип трасс, запустите визуальную студию с опцией /log из командной строки. Здесь журнал будет отброшен:

% AppData%\Microsoft\VisualStudio\12,0\ActivityLog.XML

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

И вы можете попробовать контролировать свою систему с помощью Process Explorer, чтобы узнать, замедляет ли IO или доступ к сети.

Ответ 2

У меня была очень похожая проблема с Win10 64bit. VS2015-TFS и т.д. Я решил это, изменив план питания ноутбуков с "Энергосбережения" на "Высокая производительность"...

Ответ 3

Проблема с TFS заключается в том, что она полностью интегрируется с вашей IDE.

Я предлагаю использовать GIT. Вы можете преобразовать свой проект из tfs в git с помощью различных инструментов, например git -tfs, см. https://github.com/git-tfs/git-tfs/blob/master/doc/usecases/migrate_tfs_to_git.md

Существует также сообщение в блоге о том, кто это делает: https://chriskirby.net/blog/migrate-an-existing-project-from-tfs-to-github-with-changeset-history-intact