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

VSS или SVN для проекта .Net?

На работе один из руководителей компании попросил меня исследовать, какие могут быть преимущества изменения текущего сервера управления версиями (Visual Source Safe) моего проекта на SVN.

У меня действительно нет ничего против SVN, на самом деле я его копаю, но, по моему скромному мнению, переход на SVN не принесет каких-либо значительных преимуществ для проекта и заставит нас использовать некоторые сторонние инструменты для управления исходным элементом управления из Visual Studio (мы разрабатываем, используя главным образом инструменты Microsoft).

Итак, как первый шаг в моих исследованиях, я спрашиваю вас: какие могут быть преимущества перехода от VSS к SVN?

4b9b3361

ОТВЕТЫ

Ответ 1

SVN более популярен, чем VSS, и имеет множество преимуществ. VSS устарел и устарел.

Сегодня многие разработчики переходят из VSS в SVN. Если вы будете искать "SVN" и "VSS" в Google, он покажет вам много статей, связанных с VSS для миграции SVN.

  • Модель VSS lock-modify-unlock делает сотрудничество по быстро изменяющимся файлам главной головной болью. Кроме того, накладные расходы на необходимость администратора, чтобы разблокировать файлы, которые кто-то проверил, пока они находятся в отпуске.
  • С VSS это не вопрос, потеряете ли вы данные - это КОГДА. Предполагается, что ваш исходный репозиторий является скалой - если рабочая станция разработчика падает, вы должны только потерять HIS-изменения. Вы не должны терять случайные файлы и данные из репозитория
  • VSS не поддерживается MS более 6 лет. Можете ли вы даже получить поддержку для этого?
  • В зависимости от ваших средств резервного копирования вы не сможете получить полную резервную копию своего репозитория VSS, если у вас есть только один человек, оставленный на сервере (это означает, что они оставили свои инструменты для разработчиков открытыми или покинули клиент VSS).
  • VSS требует, чтобы все пользователи имели почти полный контроль на уровне файловой системы (разрешения NTFS) файлов, составляющих репозиторий.
  • Нет хорошего, удобного и легкодоступного опубликованного API для VSS, а сторонние инструменты по большей части слабы.
  • Слияние всасывает в VSS.
  • VSS: Если у вас есть разработчики, распространяющиеся по нескольким часовым поясам, сам факт их проверки может повредить базу данных, если они проверяются слишком близко друг к другу, в неправильном порядке.

Теперь, это не означает, что Subversion безупречен - есть вещи, которые он может сделать лучше, и вещи, которые он не делает вообще. Но все люди, которые работали с VSS и SVN, скорее всего, никогда не вернутся в VSS.

Если вы выберете SVN. Ниже приведен список инструментов, которые могут вам понадобиться:

  • AnkhSVN - поставщик Subversion SourceControl для Visual Studio.
  • RapidSVN - это кросс-платформенный клиент Subversion.
  • TortoiseSVN - это простое в использовании программное обеспечение для управления SCM/source для Microsoft Windows и, возможно, лучший автономный Клиент Subversion есть.
  • VisualSVN - это подключаемый модуль Visual Studio, который легко интегрирует Subversion и TortoiseSVN с Visual Studio.
  • VisualSVN Server - это пакет, содержащий все необходимое для установки, настройки и управления сервером Subversion для вашей команды на платформе Windows. Он включает в себя Subversion, Apache и консоль управления.

Вот отличная книга на эту тему: Контроль версий с Subversion от C Pilato

Управление версиями с помощью Subversion http://ecx.images-amazon.com/images/I/51iwjNGkQdL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg

Еще одна хорошая альтернатива VSS и SVN - SourceGear Fortress, в которой система контроля ошибок помимо контроля источника - все в одном. Или SourceGear Vault - только контроль источника. Также существует SourceAnyWhere решение. Если вам требуется решение Microsoft, чем использовать TFS вместо VSS.

Ответ 2

Microsoft признала, что никогда не использовала VSS для любого из своих внутренних проектов (теперь не могу найти ссылку:/). Я использовал его два года, и это было глупо. База данных была повреждена не реже одного раза в неделю.

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

Определенно идти с SVN. VSS похож на ночные кошмары 1000 демонов.

Ответ 3

Рассмотрим более современный инструмент, например Git, Mercurial или Darcs. Есть много преимуществ, я оставлю гуглинг как упражнение для читателя.

Ответ 4

Мы используем SVN, где я работаю, и с правильной документацией, правильным клиентом и инструментами, это просто - до сих пор это очень надёжно работать. Проведя последние 10 лет с VSS, я могу сказать, что немного не скучаю.

Мне нравится SVN так, что я написал обзор того, что считаю наиболее ценными клиентами (некоторые из них не являются) и дополнительными инструментами. Это новая статья, поэтому она очень своевременна: http://codertools.wordpress.com/2009/03/24/svn-subversion-clients-and-other-tools/

Я бы без колебаний рекомендовал SVN всем - GIT следующий в моем списке, чтобы посмотреть.. Надеюсь, что это будет полезно.

Ответ 5

Избегайте головных болей в случае сбоя базы данных Source Safe, в результате чего вся ваша кодовая база с ней является крупной.

Не нужно беспокоиться о том, кто проверил файл, это другое.

Ответ 6

Я считаю, что слияние файлов с VSS очень громоздко, но это отлично с SVN. Кроме того, и у меня нет никаких доказательств этого, но SVN выглядит быстрее.

Ответ 7

VSS устарел и устарел. База данных повреждена слишком часто. Там причина, по которой MS построила TFS тоже.

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

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

Мы изменили с VSS на SVN 4 года назад, и с тех пор мы не оглядывались назад.

Ответ 8

Так же, как и в стороне, мы с удовольствием используем SourceGear Vault в течение нескольких лет. Имея репозитории и центральную базу данных SQL Server вместе с большим доступом к интернетам, он стал для вашей организации slam dunk.

Я думаю, что это разумно оцененный и, по крайней мере, стоит посмотреть.

Ответ 9

AnkhSVN 2.0 действительно очень хорош.

Если бы у вас была интеграция с Visual Studio как требование, я бы предупредил о SVN еще год назад, но это изменилось в большой степени. Это все еще не так хорошо, как, скажем, VS Team System, но это намного лучше, чем старая VSS-интеграция на базе MSSCCI. Нет причин не использовать SVN с .NET.

Ответ 10

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

  • Больше поврежденных репозиториев
  • Гораздо лучшее слияние
  • Намного быстрее
  • Дешевое и легкое ветвление
  • Больше эксклюзивной блокировки
  • Очень легко проверить источник на несколько мест.

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

Ответ 11

SourceGear Vault - отличная замена VSS. Он начинал быть "функциями VSS, но с использованием реальной базы данных", и вырос оттуда.

Ответ 12

Почти определенно SVN. SVN поддерживает другой способ работы (Copy-Modify-Merge вместо Lock-Modify-Unlock). Это немного кривая обучения, но это то, как все прошло уже несколько лет, поэтому большинству разработчиков придется в какой-то момент изучить его. Lock-Modify-Unlock - это слишком большая боль, и есть серьезные проблемы с совместной работой, на которые это действительно влияет, что я с удовольствием объясню, если вам интересно.

Посылая комментарии о том, как плохо работает VSS. Вот несколько ссылок, которые охватывают тему:

http://www.codinghorror.com/blog/archives/000660.html

http://www.developsense.com/testing/VSSDefects.html

http://wadhome.org/svn_vs_vss.html

Изменить: Смотрите также: Контроль источника - блокировка против слияния?

Ответ 13

Говоря как кто-то, кто прошел процесс перехода VSS → SVN для большой базы кода, я бы сказал, что самое большое преимущество заключается в том, что вы можете спокойно спать, зная, что ваша система SCM не будет внезапно иметь икоту, которая развращает вашу базу данных, и у вас есть вернуться ко вчерашнему резервному копированию. Вы делаете резервную копию своей базы данных ежедневно, не так ли?

С VSS коррупция происходила не реже одного раза в месяц. С SVN (такое же оборудование и ОС) - не один раз в течение двух лет.

О, и возможности ветвления/слияния сладки!

Ответ 14

Определенно, отправляйтесь с SVN по всем указанным выше причинам. Вы можете попробовать ankhsvn, который является плагином svn для визуальной студии. Таким образом, вы получаете лучшее из обоих миров: используя SVN, и вся работа по-прежнему выполняется внутри визуальной студии.

Ответ 15

Просто добавьте ответ Koista Navin.

Он сказал: "Вот отличная книга на эту тему: Контроль версий с Subversion от C Pilato

Существует бесплатная онлайн-версия:

http://svnbook.red-bean.com/

Ответ 16

Team Foundation Server - оптимальный вариант для разработки в мире .NET. Однако он не является бесплатным и для текущей версии 2008 года он может быть довольно дорогим. Если у вас есть пакет более высокого уровня для Visual Studio, вы получаете бесплатную версию рабочей группы TFS, которая позволяет без доступа к 5 пользователям получить доступ.

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

Тем не менее, Microsoft осознала это и меняет это на 2010 год. Вам больше не нужно будет приобретать сам сервер и нужно будет покупать только лицензии CAL. Лицензирование сервера TFS 2010: оно включено в подписки MSDN