Производительность в Subversion и SourceSafe

Question

Мы распределенная команда из 5 разработчиков, работающих над довольно крупным проектом интеграции. В настоящее время мы используем SourceSafe (да, я знаю , это отстой, но он работал до недавнего времени, и мы использовали его навсегда). Нашей самой большой проблемой в последнее время стала производительность. Регистрация и выход проекта занимает вечность, и мы тратим много времени на ожидание SourceSafe (да, мы отключили антивирусную проверку и все остальные триксы повышения производительности - все еще медленно).

Сейчас мы собираемся настроить и переместить все наши вещи в Subversion. Как производительность в SourceSafe через Интернет сравнивается с Subversion? Я думаю, что история не так важна для перемещения (мы могли бы просто вернуться к базе данных VSS, если нам нужен старый файл) и на самом деле перемещение файлов в Subversion должно быть проблемой - верно?

Я также хотел бы получить некоторые сведения об инструментах и ​​надстройках, которые "должны иметь", помимо реальных инструментов ядра Subversion.

Answer 1

Проверка в VSS называется commit в SVN. Эта операция выполняется во много раз быстрее, так как SVN будет передавать только внесенные вами изменения (иначе говоря, "diff"), а VSS отправит весь файл и внесет изменения на сервер.

извлечение в SVN (получение начальной рабочей копии) несколько медленнее по сравнению с другими системами, если вы используете http (s) и имеете общий (> 100 МБ) общий размер файлов. В худшем случае SVN - это множество файлов и каталогов, так как HTTP-передача будет намного медленнее, чем большие отдельные файлы.

Однако я сомневаюсь, что VSS будет быстрее, чем SVN. Общая производительность SVN быстрее, надежнее (без повреждений базы данных) и проще для понимания, чем VSS.

Хорошими инструментами являются TortoiseSVN (плагин Explorer), smartSVn (VSS-lookalike) и командная строка (гибкая) как добавил Тигрэйн в моих комментариях: AnkhSVN (интеграция Visual Studio) и subversive / subclipse для Eclipse IDE

Answer 2

Вы также можете найти этот вопрос актуальным.

Производительность

Основное различие в том, как долго отдельные операции выполняются в SVN и VSS, заключается в принципе SVN: время операции должно быть пропорционально размеру изменения, а не размеру проекта. Это лучше всего видно при использовании последней версии (VSS) и обновления (SVN). VSS «Получить последнюю версию» всегда перебирает все файлы в проекте, проверяя их состояние. Это занимает очень много времени. По сравнению с этим SVN проверяет историю проекта и манипулирует только теми файлами, которые были затронуты. В типичном сценарии это огромный выигрыш, так как чаще всего затрагиваются только несколько файлов. Даже при касании файла передача изменений в SVN происходит намного быстрее, чем в VSS, поскольку передаются только изменения по сравнению с целым файлом в VSS. То же самое верно для коммитов (Checkin), где снова SVN работает намного быстрее, когда вносит небольшие изменения в большие файлы. Это относится и к бинарным файлам, поскольку SVN также может различать их (используя XDelta в качестве ядра разностного ядра).

Самые важные инструменты

Для разработчика Visual Studio наиболее важными инструментами являются:

• TortoiseSVN - доступ к хранилищу через оболочку Windows
• АнхСВН - интеграция с Visual Studio
• некоторые также рекомендуют VisualSVN в качестве интеграции VS, но я думаю, что с AnkhSVN 2 интеграция уже достаточно хороша

Я даже дошел до того, что, имея TortoiseSVN и AnkhSVN, вам вообще не нужны "инструменты ядра Subversion". Основные инструменты командной строки чрезвычайно полезны, например, для автоматизации, но для обычной повседневной работы я никогда не использую их, и для работы TortoiseSVN или AnkhSVN их установка не требуется.

Интернет-доступ

Доступ через Интернет изначально поддерживается SVN и поддерживается очень хорошо. Для VSS вам нужны внешние приложения для этого, и, хотя они неплохие, они не равны 1: 1 по сравнению с исходной средой, а их скорость все еще не хватает.

Как конвертировать

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

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

Answer 3

Удаленный доступ намного проще с Subversion.

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

Что касается инструментов, вы, вероятно, захотите получить TortoiseSVN и, возможно, плагин для использования с Visual Studio (если вы это используете), например Ankh SVN (бесплатно).

Answer 4

Visual SourceSafe построен поверх общего доступа к файлам. Поэтому, когда вы регистрируете файл, все делается с использованием файловой системы. Таким образом, вместо того, чтобы просто отправлять текстовые файлы на сервер и все происходящее удаленно, VSS обращается к физическим блокам с диска при обращении к vss-серверу. Включая поиск файла в каталоге общих дисков и т. Д. Это примерно в 10 раз медленнее, чем протокол клиентского сервера.

Существует продукт под названием SourceOffSite, который добавляет более быстрый интерфейс в базу данных VSS, что делает VSS пригодным для использования по более медленным каналам.

Tony

Answer 5

Если вы заботитесь о сохранении своей истории, http://www.pumacode.org/projects/vss2svn преобразуется из одного хранилища в другое.

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

Answer 6

Исходя из моего опыта, это будет намного быстрее.

Я не использовал один и тот же большой проект в VSS и SVN, но я делал разные проекты в каждом и перенес небольшой проект из VSS в SVN.

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

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

Answer 7

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

LiveCD - ссылка .

Answer 8

Я согласен с @relentless относительно subversion, но я предпочитаю использовать командную строку. Чтобы научиться, нужно немного, но как только ты научишься, ты будешь быстрее.

Кроме того, если производительность является важной проблемой, возможно, вы захотите взглянуть на http://git.or.cz/,, она считается очень быстрой и надежной.