Я искал что-то похожее, когда впервые начал работать в компании, которая не имела системы контроля версий (yikes). Человек, отвечающий за разработку в то время, в основном рассматривал только вещи Microsoft, и единственный другой человек в небольшой команде разработчиков, который имел опыт работы с SCC, использовал только SourceSafe.
У меня был огромный опыт работы с SVN, так что, по общему признанию, я достаточно предвзят, но я действительно пытался провести оценку SVN против VSS против TFS. У меня действительно были проблемы с нахождением чего-либо положительного в VSS, за исключением людей, которые сравнивали его с тем, что он вообще не использовал контроль исходного кода.
Sourcesafe
Visual SourceSafe: система уничтожения источников Microsoft
- Из статьи:
- В SourceSafe отсутствует полезная поддержка ветвления [..] Поддержка слияний SourceSafe тесно интегрирована с проверкой регистрации, что затрудняет изучение различий и тестирование предложенного слияния, прежде чем вносить его в дерево. При таком слабом уровне поддержки легко проверить неработающий код в системе контроля версий.
- При обновлении локального рабочего пространства в соответствии с сервером, файлы, которые были удалены на сервере, должны быть доведены до вашего сведения. (Или удаляется, так как старую версию можно извлечь из системы контроля версий.) Невыполнение этого приводит к риску использования устаревших файлов в вашем проекте, что часто вызывает проблемы. [..] SourceSafe не может удалить устаревший файл или выдать предупреждение.
- Фундаментальный дизайн SourceSafe предполагает, что клиенты заслуживают доверия, всегда функционируют правильно и что ничто не мешает коммуникации, вызывающей повреждение данных. В результате SourceSafe является хрупким и ненадежным. Я работал с SourceSafe на трех разных работах. В каждом случае в конечном итоге база данных SourceSafe была повреждена. Данные были повреждены, работа была потеряна, время было потрачено впустую на проблему.
Контроль версий Visual SourceSafe: небезопасен на любой скорости?
- Из статьи:
- Похоже, что SourceSafe работает разумно, когда используется простой цикл создания, а затем разработки исходных файлов, проверки файлов на определенных этапах, маркировки проекта и т. Однако многие простые действия приводят к сбою программного обеспечения различными тонкими (а иногда и неубедительными) способами. «Удаленный файл может быть легко удален из базы данных, что не позволяет перестроить предыдущие версии проекта. ''
- Пользователь может разумно ожидать, что команда Destroy удалит текущую рабочую версию файла с жесткого диска пользователя. Пользователь также может разумно ожидать, что команда Destroy удалит файл из текущей версии проекта. Пользователь может не ожидать, что файл будет удален из всех предыдущих версий проекта.
CodingHorror: Контроль версий: все, кроме SourceSafe
- Из статьи:
- SourceSafe был совершенно адекватной системой контроля источников в конце 90-х годов. К сожалению, SourceSafe никогда не обновлялся архитектурно, чтобы отражать современные методы контроля версий. Даже самая последняя версия, SourceSafe 2005, абсолютно пахнет 1999 годом.
- SourceSafe создает иллюзию безопасности и контроля, одновременно подвергая ваш проект риску.
- SourceSafe учит разработчиков вредным привычкам: избегать ветвлений, эксклюзивных блокировок, простых постоянных удалений.
http://www.wadhome.org/svn_vs_vss.html
С http://svn.haxx.se/users/archive-2006-11/0242.shtml:
- VSS по умолчанию использует блокировку при работе с файлами. Если пользователь проверяет (блокирует) файл, затем покидает компанию или уходит в отпуск на 2 недели, администратор должен вручную разблокировать файл, если кому-то еще нужно поработать над ним, и когда этот другой человек вернется, вы ' у вас в руках беспорядок слияния. Слияние не очень хорошо, насколько я помню.
Короткий VSS против SVN (взят из http://better -scm.berlios.de / Сравнение / сравнение.html ):
- VSS не является атомарным - если сеть отключается, отключается питание (на сервере или клиенте) и т. Д., Хранилище повреждено. SVN является атомарным, либо входит все изменение, либо ничего не делает
- VSS блокирует файлы - несколько человек не могут работать с одним и тем же файлом одновременно
- Изменения в VSS зависят от файла. SVN может фиксировать изменения в нескольких файлах как один «набор изменений».
- VSS не отслеживает изменения в каждой строке. С SVN можно увидеть, кто последний изменил строку, и в какой ревизии ("svn blame")
1094 * Subversion *
Очень простая система управления исходным кодом. Отслеживает изменения, использует модель update-merge-commit, которая позволяет нескольким разработчикам работать над одним и тем же файлом одновременно, а Subversion автоматически объединяет их изменения (когда это возможно). Никакой "магии" не происходит.
Интеграция в Windows / Explorer через TortoiseSVN . Интеграция в Visual Studio через VisualSVN ($ 50 / разработчик) - который на самом деле является лишь интерфейсом для TortoiseSVN.
Интегрируется со многими сторонними инструментами, например:
Trac для отслеживания ошибок
Тонны плагинов / аддонов для этого на http://trac -hacks.org
CruiseControl.NET для непрерывная интеграция (автоматизированные сборки)
Свн Минусы:
Нет встроенного отслеживания слияний (отслеживание того, какие наборы изменений были объединены, например, от разработки до стабильной ветки)
Возможно с svnmerge / svnmergegui
Начиная с SVN 1.5, есть встроенное отслеживание слияния
Отсутствует функция "полки"
Позволяет кому-то работать над чем-то и "складывать" его в хранилище (не делая его частью проекта), где другие разработчики могут его забрать.
TFS имеет это
Может аппроксимировать эту функцию, используя либо патчи, либо создав отдельную ветку.
Team Foundation Server (Visual Studio Team System)
Использует SQL-сервер в качестве бэкэнда (поэтому он надежен). Имеет встроенный набор инструментов для отслеживания ошибок, планирования проекта, непрерывной интеграции.
- Розничные цены :
- 469,98 долл. США за издание для рабочих групп (ограничение 5 пользователей)
- 2499,98 долл. США за полное издание
Лицензирование может быть более сложным, чем это: Технический документ по лицензированию
- Кажется, что CAL (клиентская лицензия) необходима для каждого пользователя системы, который напрямую обращается к TFS. Например, даже для того, чтобы сотрудник техподдержки мог напрямую подать ошибку, потребовалась бы лицензия CAL для этого пользователя.
- Visual Studio Team Edition поставляется с клиентской лицензией, но отдельно они составляют ~ 500 долл. США (согласно тому, что я видел на форумах)
- Это может быть изменение в TFS 2008
Миграция с VSS на TFS: http://manicprogrammer.com/cs/files/folders/st_jean/entry1118.aspx
Проблемы с производительностью: http://www.cornetdesign.com/2007/05/vststfs-performance.html
- http://weblogs.asp.net/rosherove/archive/2007/04/29/tfs-or-not-being-a-perfectionist-is-a-realistic-world.aspx
- http://jeremydmiller.blogspot.com/2005/07/impressions-from-vsts-talk-last-night.html
- Из статьи:
- VSTS явно нацелен на очень крупные компании, использующие кропотливые, высокие церемониальные процессы - все, чем не является мой работодатель. Я думаю, что автоматизация процессов - это здорово, но если ваш процесс настолько сложен, что никто не может знать его целиком, я думаю, у вас есть серьезные проблемы.
- Одной из частей презентации, где я думал, что Menegay был совершенно не в духе своей идеи, была идея о том, что VSTS стал инструментом ориентированного рабочего процесса, чтобы рассказать всем (особенно разработчикам), что именно им следует делать. Как инструмент отслеживания для ведения учета проектов, я считаю, что VSTS великолепен. Использование чего-то вроде VSTS в качестве основного канала связи абсурдно. Превращение разработчиков в безмозглых зомби, делающих именно то, что говорит им рабочий процесс VSTS, звучит как рецепт катастрофы для меня. Не говоря уже о резком снижении удержания разработчиков.
- http://codebetter.com/blogs/eric.wise/archive/2007/05/31/bye-bye-team-foundation-server.aspx
- Из статьи:
- Я действительно постарался сделать так, чтобы сервер Team Foundation полностью встряхнулся. Мое мнение об этом таково: 1. В целом, система контроля версий лучше, чем безопасная. 2. Это действительно дорого. 3. Это боль в заднице, чтобы управлять. 4. Боль в заднице - устранять неполадки.
- Судя по всему, поддержка слияний / веток не так хороша, как subversion, потому что они пытались сделать ее "знакомой" для пользователей SourceSafe. Это чисто анекдотично.
Мое супер-быстрое резюме:
- VSS отстой
- TFS кажется очень удобным / способным, но довольно дорогим, как только ваша команда превосходит 5 человек
- SVN пригоден для использования и хорошо себя зарекомендовал, и не требует затрат
К чему это привело нас - возможные преимущества TFS не стоили огромных дополнительных затрат.
Что бы это ни стоило, теперь, спустя пару лет, я написал это. Парня, который раньше был ответственным, больше нет в компании, я теперь менеджер по развитию, и наша команда в 3 раза больше. Мы используем комбинацию SVN, VisualSVN + TortoiseSVN и Trac. Я не думаю, что кто-то в dev мог представить, что больше не использует эти инструменты. Каждый мог очень быстро освоить SVN, за исключением, возможно, слияния ветвей, что некоторые до сих пор не уверены в том, чтобы делать это самостоятельно.
Джефф Этвуд (создатель stackoverflow) немного обсуждает SVN на одном из своих подкастов и Джоэла: http://blog.stackoverflow.com/2008/06/podcast-10/