TFS vs SVN

Ответ 1

Ну, для меня, очевидно, выбор TFS:

• Интеграция SVN в Visual Studio, по меньшей мере, неполна (многие функции недоступны из IDE) и немного багги (безусловно, AnkhSVN), в то время как TFS один совершенен (что имеет смысл...). У меня было повреждено все рабочее пространство несколько раз, используя SVN (в течение одного месяца), никогда не используя TFS (aprox 2 years)

• Хотя связанные с Source-Control функции обеих систем, вероятно, весьма эквивалентны, они доступны непосредственно из IDE с помощью TFS, тогда как вы должны полагаться на TortoiseSVN или других внешних инструментов, если вы используете SVN. Почти все задачи TFS доступны за несколько кликов на вкладке проводника решений.

• Слияния намного проще с TFS, даже для сложных слияний (например, SVN добавит < < < < < < < < < < < < < < < lt; < и → → → → > к вашим файлам .csproj, поэтому вам придется вручную их отредактировать, чтобы снова открыть их из VS.)

Хотя я думаю, что этих причин более чем достаточно, чтобы предпочесть TFS над SVN, я добавлю, что:

• TFS - это больше, чем просто инструмент управления исходным кодом (подумайте о рабочих элементах, портале проектов и т.д.)

  Я использовал его в проекте среднего размера (12 кодеров, 3 тестировщика, 3 бизнес-аналитика) в прошлом, и нам удалось успешно централизовать все задачи в TFS (отчеты об ошибках, проектная документация, процесс сборки и т.д.)

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

Чтобы оставаться справедливым, вот два очевидных недостатка TFS:

• Его цена

• Установка TFS - это довольно боль, а установка SVN - это несколько минут.

  Установка TFS 2008 поверх SqlServer 2008 довольно сложна, вы не можете установить TFS на PDC и т.д. Для меня это определенно худший опыт установки, который у меня когда-либо был с продуктом Microsoft.

  При этом, как только установлено, TFS очень прост в использовании (особенно для кодеров, не знакомых с системами управления версиями)

В моем текущем проекте я начал с SVN и быстро переключился на TFS. Я счастлив, что сделал.

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

На сегодняшний день я не нашел единственной причины сожалеть о переключении на TFS.

Ответ 2

" Нельзя сравнивать между TFS и SVN"

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

Оба имеют приятные возможности использовать надстройки интеграции IDE (например, AnkhSVN, надстройка Collabnet), доступные для VS2005, так что это не следует рассматривать.

Критерии для выбора:
 - Если у вас нет или бюджетного проекта, выберите SVN
 - Если вы ищете систему контроля версий, выберите SVN, если вы ищете полное управление разработкой, выберите TFS
 - Если у вас есть терпение, чтобы манипулировать различными инструментами интеграции (CruiseControl.Net, NUnit, NCover, FIT) для достижения надлежащей среды разработки, выберите SVN, или если вы ищете из коробки реализацию всех для вас затем выберите TFS

Ответ 3

Воспользовавшись TFS 18 месяцев назад, я обнаружил, что это багги, медленные, раздражающие, очень ограниченные критерии поиска, и у него было ощущение, что продукт выскочил из команды, не заинтересованной, под платной, над работами техников, которые вынуждены использовать Sharepoint и другие технологии MS, потому что это то, что нужно маркетингу. Серьезно это была собака, я бы скорее использовал SourceSafe!

С другой стороны, SVN - это бит-техник, интеграция IDE - это боль, и иногда это может запутаться, но база пользователей массивная, и большинство проблем можно решить с помощью быстрого запроса SO.

Вы считали Vault? Хорошо работает и не слишком дорогой.

Ответ 4

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

• Невозможно сразу отправить несколько файлов в инструмент diff. Это смешно полезно, когда вы хотите просмотреть свои изменения до слияния и недоступны.
• Непоследовательная доступность функциональности. Некоторые функции доступны только в среде IDE, в то время как другие части доступны только в Проводнике Windows, в то время как другие доступны только из командной строки.
• Добавление файлов в элемент управления версиями недоступно из среды IDE и доступно только из интеграции Windows Explorer.
• Доступ к наборам полки доступен только в среде IDE и недоступен через интеграцию с проводником Windows.
• Отсутствие единого унифицированного установщика. Недостаточно просто установить TFS, вам также нужно установить командные инструменты и инструменты для обеспечения базовой функциональности.
• Функциональность набора полки не сливается. Что могло бы быть классным способом создания частных веток, по сути гарантирует, что ваш код устареет и перестанет работать.
• Вы должны вручную разблокировать текстовые файлы перед их редактированием, если вам нужен редактор, отличный от Visual Studio.
• Иногда Visual Studio забывает разблокировать файлы, которые он сам управляет, и выдает ошибку.
• Проверка и отложенные пользовательские интерфейсы содержат доступные файлы для фиксации того, что уже было добавлено в TFS, а не то, что действительно присутствует в файловой системе. Это позволяет легко пропустить файлы. (На самом деле это проблема с тем, как Visual Studio обрабатывает файлы проекта, но это само по себе является еще одним напылением).
• Нет необходимости использовать инструменты Microsoft для редактирования вашего источника из-за вышеупомянутых проблем.
• Конфигурация TFS выполняется с вашим источником. Это означает, что если вы измените свой сервер TFS, конфигурация для всей вашей истории теперь некорректна. Существует конфигурация по умолчанию, которую вы можете использовать, которая переопределяет это поведение, но это не очевидно.
• Нет поддержки фильтров игнорирования ни на чем, кроме базового уровня.
• Невозможность обработки путей длиной более 249 символов.
• Файлы, которые были разблокированы, но не отредактированы, отображаются как измененные, хотя они еще не были. Дифференциация между измененными и разблокированными сделает его намного легче для различий или еще лучше устраняет всю сломанную систему разблокировки.
• Оверлей значков проводника Windows явно не показывает, был ли отредактирован файл. Весь файл в TFS имеет зеленый угол, а измененные файлы добавляют карандаш к нижней части значка. Переход на красный угол для изменения был бы намного легче увидеть или использовать систему черепах значков.
• У старых версий Visual Studio есть проблемы с интеграцией в более новые версии TFS. Это означает, что теперь у нас есть зависимость версии IDE от источника управления.
• Включает файлы пользовательских решений по умолчанию, когда они не нужны. Конечно, я признаю, что это может быть вопросом предпочтения.
• Плохое кэширование позволяет неточно отражать различия между локальной копией и сервером. Это очень неприятно, чтобы получить последние и найти, что у вас на самом деле нет последних.

Ответ 5

Прошло уже 1,5 года, когда я использую SVN для различных проектов. Настройки, которые я использовал до сих пор:

• AnkhSVN клиент для Visual Studio. Он отлично сочетается с поставщиком Source Control с версии 2.
• Серверы CollabNet Subversion для Windows или Apache 2.2 с поддержкой SSL + SVN через DAV на Linux.

У меня не было никаких проблем с любой из этих настроек, и я определенно рекомендую использовать SVN, поскольку он бесплатный и простой в использовании. Также многие пакеты отслеживания проектов/ошибок интегрируются с SVN (например, trac).

Ответ 6

Я бы выбрал SVN. Ранее я работал с SVN с точки зрения разработчика, и теперь я работаю с TFS, и позвольте мне сказать вам, что TFS болезненна. В то время как TFS является полнофункциональной и больше, чем просто контроль версий, ее контроль версий в лучшем случае неаккуратный. Слияние - ужасно, и многие из нас теперь обращаются к инструментам ручного слияния или слияния, потому что мы не можем полагаться на TFS. Файлы пропадают, иногда не загружаются в локальную систему, и в его поведении есть просто странности, из-за которых вы хотите ударить головой о стол.

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

Ответ 7

Ознакомьтесь с этой статьей, прежде чем решите: Сравнение TFS vs Subversion для проектов с открытым исходным кодом

Ответ 8

Я использовал оба варианта - но на самом деле я переключил свои основные проекты с TFS на SVN. Я считаю, что автономный и анонимный доступ очень ценен в моих проектах.

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

Ответ 9

Если вы знакомы с svn, я буду придерживаться его. Tfs не является бесплатным и не прост. Это намного больше, чем просто контроль источника. Если вы являетесь магазином .net, подобным нам, и вы решаете, какой продукт использовать для всего цикла dev, он является соперником, но для простого управления источником он переполняется.

Ответ 10

Я бы сказал, что TFS - это больше, чем просто контроль источника. Если вы можете себе это позволить, я определенно советую использовать его. Когда вы, например, начинаете использовать Team Builds или используете такие вещи, как "Рабочие элементы", вы увидите, что TFS действительно может управлять всем вашим жизненным циклом разработки, обеспечивая богатую среду, в которой отчеты, простота использования, гибкая интеграция VS и надежный источник управление все включено в один.

Это требует некоторого железа на стороне сервера. Я не считаю, что он медленный, но он отлично работает через VPN и поддерживает автономную работу.

Основной кон - процесс установки (на стороне сервера), который является утомительным, негибким и на мой взгляд (я исхожу из области, в которой упаковки приложений и развертывания очень важны) - плохой пример того, как SQL Сервер, службы Reporting Services, Sharepoint и веб-службы могут быть установлены.

Ответ 11

TFS может импортировать из SVN, однако SVN не может импортировать из TFS. Поэтому, если вы не нашли хорошей причины, используйте SVN, так как легче изменить свой разум позже.

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

Ответ 12

По моему опыту SVN в целом намного быстрее и безболезненно. Я использовал его с сценариями развертывания XCOPY, которые позволяют работать и развертываться гораздо быстрее по сравнению с TFS.

Ответ 13

У меня нет опыта работы с TFS, но интеграция IDE - это то, о чем вы должны думать. TFS, очевидно, очень хорошо интегрируется с Visual Studio. AnkhSVN, единственный полезный бесплатный плагин для VS, часто бывает проблематичным даже в новых версиях. Однако я не пробовал VisualSVN.

Ответ 14

Учтите, что TFS 2010 можно установить также на клиентские ОС Windows Vista/7 и что он поддерживает экспресс, три клика, установку.

Ответ 15

Плюсы:

• Интеграция с Visual Studio. Настоящий плюс, если вы используете полную технику Microsoft. стек для разработки.
• Автоматические сборки (хотя и достижимы с помощью других продуктов) действительно красиво сделаны. Непрерывная интеграция и встроенные сборки регистрации - это фантастическая ИМО.

Минусы:

• Windows Workflow Foundation. По какой-то причине Windows Workflow Foundation был выбран в качестве метода настройки многих аспектов TFS. Короче говоря, вам нужна книга по Windows Workflow, чтобы понять ее, и у меня просто нет времени. Очень разочаровывает ИМО.
• Управление проектами. Понятие рабочих предметов достаточно простое, я думаю, но там много странностей, которые просто оставляют меня смущенным. Это просто слишком сложно ИМО. Исходя из фона Trac + SVN, я предпочитаю Trac здесь. Опять же, только мое мнение.

Ответ 16

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

В то время как я полностью согласен с сторонниками SVN, так как это великолепный инструмент (я много раз его использовал в университете), я обнаружил, что TFS, как правило, более кооперативен в ситуациях OOTB, когда вы используете SP1 Версия с Studio 2010.

Кроме того, есть несколько приятных плагинов, которые делают TFS более приятным для тех из нас, кто привык, и обычно предпочитают решение типа SVN, и многие из них имеют отличную поддержку:

TeamReview для обзора кода - один из примеров: http://teamreview.codeplex.com/ MS Pathways для многоплатформенного использования TFS: http://www.microsoft.com/pathways/teamprise/FAQ.htm

Этот SO-вопрос - это отличные ресурсы для аддонов TFS: Какие надстройки/утилиты доступны для TFS?

Слово мудрому, как упоминалось выше, TFS может быть болью, которую нужно установить, поэтому следует проявлять осторожность. Следуя приведенному ниже маршруту, я столкнулся с минимальными проблемами:

Студия 2008 → Патч → Студия 2010 → Патч → .NET → SQL Server 2008RD/2012 → Патч → TFS → Патч