Какой способ взаимодействия с SourceSafe является более быстрым? Командная строка или объектная модель?

Я должен представить, что командная строка реализована внутри с тем же кодом, что и в объектной модели, поэтому, если не требуется большого количества запусков, это не должно иметь большого значения.

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

Вы можете исследовать теневые каталоги, чтобы всегда была доступна последняя версия, поэтому вам не нужно каждый раз выполнять getlatest, и вы можете быть уверены, что разговариваете с локальным VSS (поскольку все команды выполняются непосредственно на файловая система, поэтому операции WAN чрезвычайно дороги).

В противном случае вы застрянете, если не захотите использовать другой SCM (и я рекомендую SVN - есть отличный конвертер, доступный на codeplex для него, с примером кода, показывающим, как использовать объектные модели VSS и SVN)

VSS использует подключенную файловую систему для совместного использования базы данных. Когда вы получаете файл из SourceSafe, он работает на уровне файловой системы, что означает, что вместо того, чтобы просто отправить вам файл, он отправляет вам все блоки диска, чтобы найти файл и файл. Это добавляет намного больше транзакций и дополнительных данных.

При использовании VSS через удаленное или медленное соединение или с огромными проектами он может быть практически непригодным для использования.

Существует продукт, который, помимо прочего, увеличивает скорость VSS примерно в 12 раз при использовании по сети. Это достигается за счет реализации клиент-серверного протокола. Это дополнительно может быть зашифровано, что полезно при использовании VSS через Интернет.

Я не работаю и не имею с ними никакого отношения. Я просто использовал его в предыдущей компании.

см. SourceOffSite на сайте www.sourcegear.com.

Отвечая на единственную часть вашего вопроса, которая, кажется, имеет какое-то существенное значение - переключение на объектную модель не будет происходить быстрее, поскольку «медлительность» исходит из протокола, используемого для обмена файлами между VSS и базой данных - см. Мой другой ответ.

Упомянутый мной продукт работает вместе с VSS для решения вашей проблемы. Вы по-прежнему используете VSS и ahev, чтобы иметь лицензии на его использование ... он просто ускоряет его там, где вам это нужно.

Не уверен, почему вы отметили меня ?!

С тех пор мы обновили систему управления версиями до Team Foundation Server. Когда мы использовали VSS, я заметил то же самое в журналах сборки CruiseControl.Net (предостережение: я никогда не исследовал, что использует CC; я предполагаю, что это командная строка).

По своему опыту могу сказать, что проблема в VSS. Наша TFS расположена на расстоянии более 1000 миль и работает быстрее, чем когда серверы были разделены примерно 6 футами кабелей Ethernet.

Изменить: чтобы надеть мою деловую шляпу, если вы сложите время, потраченное на ожидание сборок + время, потраченное на их ускорение, может быть достаточно, чтобы оправдать обновление или надстройку VSS, упомянутую в другом сообщении (уже +1 Это). Я бы не стал тратить много времени на создание решения на VSS.

Держу пари, что запуск объектной модели будет медленнее как минимум на 2 часа .... ;-)

Как используется инструмент командной строки? Вы не случайно вызываете инструмент один раз для каждого файла?

Это не похоже на это («рекурсивное получение» в значительной степени подразумевает, что это не так), но я подумал, что добавлю эту мысль. У других могут быть проблемы, похожие на ваши, и это кажется пугающим обычным явлением для систем управления версиями.

ClearCase на одном клиенте работал как настоящая собака, потому что это делали серверные скрипты клиента. Каждый вызов командной строки создает соединение, аутентифицирует пользователя, получает файл и закрывает соединение. Десятки тысяч раз. О, опасность интерфейса командной строки и немного Perl.

С API вы, скорее всего, правильно будете держать сеанс открытым между действиями.