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

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

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

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

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

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

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

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

Судя по моему опыту, это будет намного быстрее.

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

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

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

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

LiveCD - связь.

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

Представление

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

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

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

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

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

Доступ в Интернет

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

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

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

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

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

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

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

Хорошими инструментами являются TortoiseSVN (подключаемый модуль проводника), smartSVn (аналог VSS) и командная строка (гибкая). как Tigraine добавил в мои комментарии: AnkhSVN (интеграция с Visual Studio) и subversive / subclipse для eclipse IDE

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

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

Тони