SVN против Team Foundation Server [закрыто]

вот самые большие различия между ними для меня, и я использовал оба:

1) TFS довольно тесно связан с" способом Visual Studio " выполнения разработки. это не значит, что TFS тесно связана с vs IDE, это означает, что TFS изо всех сил пытается сохранить знакомую парадигму "check in"/"check out" Visual SourceSafe, даже когда она действительно больше не является подходящей моделью. Концепция Subversion "commit" / "update" намного более реалистична, когда вы есть разработчики, которые могут тратить время на отключение от сети. TFS ожидает, что разработчики всегда будут подключены к серверу. Это большой минус. Я лично считаю, что TFS менее прозрачен о том, как файлы организованы на сервере и на локальном диске из-за жесткой интеграции Visual Studio. Даже более крупные сторонники TFS признают, что его подключенная модель регистрации/выписки не является убедительным вариантом для разработчиков, которые работают в отключенном режиме. В климате, где живут люди начиная смотреть на варианты DVCS, такие как git и Mercurial над SVN, модель "check out" TFS кажется немного похожей на динозавра.

2) стоимость. те, кто говорит, что TFS не дорого, либо, вероятно, очень маленькие магазины, либо не соответствуют лицензионным условиям TFS. Вам нужна лицензия клиентского доступа для штопать почти все, что вы делаете. Вы менеджер, который просто управляет ошибками? Вам нужен ~ $ 250 CAL (есть 5 в комплекте с розничной лицензией TFS). Бизнес-пользователь, который просто хочет сообщить о своих проблемах? $ 250 КАЛ. Разработчик? $250 (Если у них нет MSDN, в этом случае он включен). Сервер? $500 (включено, если у вас есть MSDN). Конечно, кто-то, продающий вам копию TFS, скажет вам, что отслеживание рабочих элементов бесплатно для дополнительных пользователей, но эти дополнительные пользователи могут видеть только те рабочие элементы, которые они сами создают, а не рабочие элементы всей команды, что не слишком полезно в ориентированной на команду гибкой среде. Все это складывается, когда у вас есть организация среднего размера, и становится трудно оправдать, когда так много лучших в своем роде продуктов, таких как SVN и CruiseControl.net добавочная стоимость составляет $0. (Справедливости ради TFS, однако, я все еще жду действительно good OSS issue tracker)

3) структура проекта. в больших командах с меньшим количеством проектов, TFS, вероятно, будет работать хорошо. Если вы являетесь несколькими небольшими, несвязанными или слабо связанными бизнес-приложениями внутри компании, TFS структура может начать становиться властной. Во-первых, невозможно определить таксономию самих проектов-вы можете настроить "области" внутри проекта, но все вопросы и документы отслеживаются вместе в базовом контексте "проекта". Создание новых "проектов" часто занимает много времени и является излишним для небольших усилий. Конечно, SVN не имеет ничего подобного, поскольку он фокусируется только на управлении исходным кодом, но если вам нужна хорошая гибкость малого проекта, SVN и другая проблема средство отслеживания может быть лучшим выбором.

мое мнение, для чего это стоит:

• для больших команд с большими, хорошо финансируемыми проектами, в магазине Microsoft, где разработчики работают почти исключительно в среде IDE, TFS является победителем. TFS также выигрывает, когда вам нужно централизованно применять политику с вашими проектами.

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

Я удивлен, что кто-то, кто использовал Subversion в прошлом, даже хотел бы/нуждался в управлении исходным кодом TFS.

мой опыт работы с TFS (2005) был довольно ужасен. Я прочитал все виды технических документов и руководства о том, как правильно структурировать свой источник для различных потребностей развития.

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

мои основные проблемы с TFS:

• слияние-это боль по сравнению с подрывной деятельностью.
• есть неисправленных ошибок. Я столкнулся с одним из переименований / слияний, который был известен в течение 2 лет, и исправление никогда не будет выпущено в 2005 году. Мы закончили тем, что переместили нашу ветку в "сломанную" папку, и теперь мы ее игнорируем.
• установка блокировок только для чтения на ваших файлах есть трение. Кто сказал, что мне нужно редактировать пакетные файлы и создавать скрипты внутри TFS, чтобы он "проверил это" для меня? Подрывная деятельность знает измененные файлы. Там нет блокировок только для чтения.
• скорость. TFS медленно работает по WAN, и это действительно можно использовать только в том случае, если я VPN на своем рабочем компьютере, что делает мой опыт разработки очень медленным в целом.
• отсутствие хорошей интеграции командной строки и проводника. Интеграция IDE действительно хороша для ежедневные обновления, добавление файлов и регистрация, но когда вам нужно делать что-то во многих проектах, приятно иметь в своем распоряжении хорошие инструменты. И прежде чем кто-то прыгнет мне в горло, требуя tf.ехе работает хорошо... это не совсем инструмент линии cmd. Например, при проверке кода не должно появляться модальное диалоговое окно.

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

мы a VS.NET магазин, и мы реализовали:

1. ошибка для отслеживания проблем
2. Apache Subversion в качестве исходного кода репозитория back-end
3. VisualSVN Server для управления SVN на сервере
4. TortoiseSVN (в Windows Explorer) и AhnkSVN или VisualSVN (в Visual Studio) на клиент
5. CruiseControl.NET для автоматических сборок

стоимость: $0 Преимущества: Бесценный

Если вы небольшая команда, или не готовы купить в процессе ВОЗ TFS, SVN и инструменты с открытым исходным кодом-это путь.

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

1) Если вы используете TFS 2005, выполните обновление до TFS 2008. Ты меня поблагодаришь. Есть тонна улучшений в TFS 2008, которые делают его работоспособным.

2) Если вы живете в Visual Studio и хотите интеграцию с IDE, перейдите к TFS. Я использовал SVN интеграция и почти всегда возвращаются к использованию TortoiseSVN.

3) Если вам нравится идея интеграции учетных записей с проверкой подлинности Windows, перейдите к TFS. Управляемость с этой стороны хороша. Там могут быть крючки для SVN-я не уверен, но если вам нравится управление с графическим интерфейсом, TFS трудно победить.

4) Если вам нужно отслеживать показатели или иметь более простые способы реализации таких вещей, как политики регистрации, перейдите к TFS.

5) Если у вас есть люди, которые не будет реализовывать его, если это не MSFT, идите с TFS.

6) Если вы делаете больше, чем просто .NET (Java work, Eclipse и т. д.), идите с SVN. Да, есть очень хорошие продукты (например, Teamprise), которые хорошо работают с TFS. Но если другие языки не являются небольшой частью вашего магазина, просто придерживайтесь SVN.

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

TFS действительно не так дорого ($1200 может быть?). По сравнению с SVN это, пожалуй. Интеграция со службами reporting services и SharePoint хороша, но опять же, если вы не используете это, то это не имеет значения.

Что я бы сказал, чтобы загрузить 180-дневную пробную версию TFS и дать ему идти. Запустите пробную версию бок о бок. Я думаю, что вы будете счастлив независимо от того, в какую сторону вы идете.

Как указывает Убигучи, TFS не является продуктом управления версиями. Покупка TFS с намерением использовать его только для контроля версий, очевидно, будет пустой тратой денег. TFS-это интегрированный набор инструментов для автоматизации всех аспектов управления жизненным циклом приложений (и в значительной степени ориентирована на "предприятии".

также за пост Бена S - Я не понимаю вашего комментария о замках. Блокировки не требуются в TFS вообще. Администраторы могут настроить TFS для работы как VSS (особенности, требуемые некоторыми "неразумными" клиентами), чтобы "получить последнюю информацию о проверке", которая, как я считаю, также делает блокировку выписки.

но через " обычное "использование TFS A" check-out "запрашивает пользователя для типа блокировки - и по умолчанию должно быть"нет". Пользователь может выбрать регистрацию отъезда (или блокировку регистрации)-но это не обязательно. Если вам не нужны замки, не используйте их.

TFS отслеживает, какие пользователи имеют проверки на сервере по различным причинам производительности (make get-latest быстрее) и управление проектами (мне нравится видеть, какие разработчики проверили файлы и как долго их проверки).

Я не очень хорошо знаком с SVN (я никогда не использовал его) - поэтому я не могу прокомментировать, что "слияние хуже с TFS" - и не попал в сообщение об ошибке слияния Ben S, но у меня был большой успех с ветвлением и слиянием с использованием TFS.

один случай использования я знаю, что TFS все еще довольно слаб для пользователей, которые регулярно "отключены". TFS - это "серверный продукт", который предполагается, что пользователи подключены большую часть времени. Автономный опыт улучшился в выпуске 2008 года (он был мрачным в 2005 году), но все еще предстоит пройти долгий путь. Если у вас есть разработчики, которые нуждаются (или хотят) часто отключаться от сети в течение длительного периода времени - вам, вероятно, лучше с SVN.

еще одна особенность, чтобы рассмотреть для поклонников SVN, которые используют TFS является СВН мост codeplex, который позволяет пользователям использовать TortiseSVN для подключения к TFS. Я мой хороший друг и коллега широко использует его и любит его.

также Меня удивляет комментарий об отсутствии командной строки - инструменты командной строки обширны (хотя многие требуют отдельной загрузки TFS Power Tools

Я подозреваю, что комментарии Бена основаны на оценке выпуска 2005 года, который явно был продуктом "Microsoft V1.0". В настоящее время продукт находится в версии 2.1 с версией 3 в ближайшем будущем.

TFS-это отвратительно. На данный момент я контролирую версию локально, используя SVN (w/ Live Mesh для резервных копий), потому что у меня есть много проблем с TFS. Основная проблема заключается в том, что TFS использует метки времени для записи, если у вас есть последняя версия, и сохраняет эти метки времени на сервере. Вы можете удалить свою локальную копию, получить последнюю версию из TFS, и она скажет, что все файлы обновлены. Это глупая система, которая не дает вам никакой гарантии, что у вас есть правильная версия файлов. Это приводит к многочисленным раздражения:

• TFS должен быть проинформирован, когда любой файл редактируется, так что вы должны быть подключены к серверу в любое время.
• TFS запутаться, если вы редактируете файлы за пределами IDE. Далее он устанавливает все файлы только для чтения в NTFS.

в то время как TFS поддерживает слияние, это действительно система проверки/проверки. Если вы редактируете файл, вы часто обнаружите, что он заблокирован для других разработчиков. Есть способы обойти это, но система настолько запутанная вы всегда будете сталкиваться с этой проблемой. Например, наши разработчики обнаружили, что они могут обойти все файлы, настроенные только для чтения в NTFS, проверив все решение, которое устанавливает эксклюзивную блокировку всех файлов. Я сделал это несколько раз, потому что subversion имеет тот же синтаксис для проверки, который не получает блокировки.

наконец Team Explorer (клиент) - это колоссальные 400 МБ, сервер TFS требует SharePoint и два дня для установки. Subversion One click installer-это примерно 30 МБ, и он установит сервер для вас менее чем за минуту. TFS имеет много функций, но его основа настолько шаткая, что вы никогда не будете использовать или заботиться о них. TFS стоит дорого с точки зрения лицензии, и со временем разработчики будут тратить разглагольствования на stackoverflow вместо написания кода: P

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

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

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

вот версия VisualSVN с открытым исходным кодом под названием Ankhsvn. Его гораздо лучше теперь, когда collabnet взял его на себя.

Если все, что вам нужно, это управление версиями, TFS является излишним. Один из моих предыдущих работодателей имел TFS, VSS и Subversion на своем предприятии. У нас не было Active Directory или Exchange Server 2003 на нашем предприятии, поэтому мы создали отдельных пользователей на сервере TFS, чтобы разработчики могли его использовать. У нас были те же самые проблемы с слиянием, о которых упоминал Бен Ширман, наряду с другим поведением багги, которое подтолкнуло нас к подрывной деятельности.

является ли TFS правильным вызовом вы будете частично зависеть от вашего бюджета, размера вашей команды разработчиков, а также количества времени и персонала, доступных для настройки/обслуживания вашего решения. Если вам нужны дополнительные возможности отслеживания проблем, рабочих элементов и статистики проектов, предоставляемые TFS, возможно, стоит посмотреть на другие альтернативы. Такие продукты, как JIRA (от Atlassian Systems) или Trac, хорошо интегрируются с Subversion и обеспечивают такой контроль, который может быть у менеджера проекта или программы более низкая цена.

в идеальной среде с Active Directory, Exchange Server 2003 или выше и выделенным персоналом для репозитория TFS, скорее всего, будет хорошим выбором.

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

1. VisualSVN Server это полный сервер SVN с хорошим плагином для управления им. Он позволяет использовать проверку подлинности windows прямо через пользовательский интерфейс. Простой.

2. Черепаха его черепаха, достаточно сказал.

3. ankhsvn это отличный плагин SCC. Для тех, кто хочет полную интеграцию с IDE, последняя версия-это полный плагин SCC. Таким образом, теперь вы получаете полную интеграцию бесплатно.

вышеуказанная настройка на 100% бесплатна и поможет вам пройти через все, что вам нужно для управления версиями.

TFS-это не только система управления версиями. Если вы используете весь пакет, который предлагает TFS, отслеживание ошибок, сборки, отчеты и т. д., то TFS-довольно солидный выбор (конечно, лучше, чем Rational). TFS также хорошо интегрируется с Active Directory.

хотя, если вы просто говорите о SCM, то я предпочитаю SubVersion. Мне не очень нравится интеграция IDE. Мне также нравится соглашение SVN о структуре ствола / тегов / ветвей и относительная простота переключения между ветвями. Слияние казалось легче в TFS, хотя. Однако пользовательский интерфейс Tortoise бьет по рукам TFS, особенно в отношении добавления файла в репо.

Я бы сказал, Это действительно зависит от ваших потребностей. TFS очень хорош, я широко использовал его, но он очень нацелен на уровень предприятия, если вам не нужны все эти функции, это может быть не нужно. Если вам нужны эти функции (особенно ветвистые, масштабируемость, отслеживание рабочих элементов, и т. д.) они стоят каждого пенни. Имейте в виду, что TFS включает отслеживание ошибок, отслеживание рабочих элементов и другие функции вне системы управления версиями. Если у вас есть несколько филиалов или если вы окажетесь борьба с некоторым отсутствием функции или другой в Subversion, то это может быть хорошей идеей, чтобы переключиться. Но если у вас нет веской причины для переключения, вы, вероятно, должны избегать снижения стоимости и производительности систем управления источниками переключения.

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

тем не менее, я могу честно сказать, что SVN и TFS кажутся довольно равными в отношении масштабируемости, и если что-то SVN source control имеет преимущество на TFS из-за присущей ему простоты.

Если вы хотите отслеживать работу и ошибки вместе с вашим исходным кодом, то вы либо идете на TFS, либо идете с SVN и некоторые другие, возможно бесплатные, инструменты, такие как bugzilla. Хотя TFS интегрирует как управление версиями, так и отслеживание рабочих элементов вместе, я честно думаю, что MS должна была отдать его бесплатно в качестве извинения за злоупотребление таким количеством разработчиков с VSS на протяжении многих лет.

Я использовал как SVN, так и TFS. Главным преимуществом использования TFS является его тесная интеграция с Visual Studio. Отслеживание ошибок, отслеживание задач будет все идти в одном месте. И отчеты, созданные для этих пунктов, помогут держателям акций быть в курсе состояния проекта.

Я работаю над проектом с 5 людьми, и мы недавно переключились с SVN на TFS. Весь процесс был кошмаром. У нас есть автоматически сгенерированный код из XMLSpy, и TFS не распознает файлы, измененные за пределами VS2008. TFS Power Tools может сканировать ваш заказ и исправить эту проблему, но это боль, чтобы помнить, чтобы использовать эти инструменты. Еще одна проблема, с которой мы постоянно сталкиваемся, - это инструмент слияния по умолчанию в TFS. Это, безусловно, худший инструмент слияния, который я когда-либо использовал. Можно было бы думаю, что TFS сможет обрабатывать основные слияния решений, но до сих пор этого не было.

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

Адам

TFS отлично подходит для управления проектами и отслеживания, однако я чувствую, что управление версиями не так хорошо, как SVN. Вот мои подводные камни с TFS:

регистрация заезда/отъезда модель

Это огромная афера для системы управления версиями TFS. К сожалению, VS автоматически проверяет элементы для вас, даже если вы этого не хотите. Я был в ситуации, когда кто-то проверил некоторые файлы, а затем ушел в отпуск. Я отвечал за реструктуризацию структуры каталогов, но не смог, потому что куча файлов были проверены на этого человека. В графическом интерфейсе нет способа отменить проверку, что означало, что это должно было быть сделано один за другим в командной строке. Или мне нужно было выяснить, как написать сценарий power shell для этого.

VS требуется сделать все

иногда я хочу отредактировать текстовый файл и проверить его. Для этого мне нужно запустить VS 2010, который является огромным зверем, просто отредактировать файл и проверить его. Что-то такое прошло несколько секунд с SVN теперь занимает у меня минуту.

как указывали некоторые другие, файлы помечаются только для чтения, если они не извлечены. Если вы сделаете его доступным для записи и отредактируете его за пределами VS, TFS не распознает это. Это делает редактирование чего-то вне VS раздражающим. Это означает, что запуск VS, проверка файла, редактирование его другим редактором, проверка в VS.

некоторые операции, которые были просты в SVN теперь a боль

• может быть, я еще не понял этого, но я обнаружил, что откат набора изменений был очень утомительным с TFS.

• добавление файлов в систему управления версиями, которые не являются частью решения, является огромная боль. Проводник системы управления версиями TFS показывает только те файлы, которые находятся в системе управления версиями, а не те, которые нет (возможно, где-то есть настройки для этого, я не знаю). С Tortoise SVN я мог просто нажать Commit на папку и выберите файлы для добавления.

в настоящее время я возглавляю усилия по оценке TFS в моей компании против Rational Suite, который мы в настоящее время используем. До сих пор TFS 2008-это pwning clearcase + clearquest. Интеграция среды разработки-это то, где она действительно сияет.

мои 10 копеек:

TFS2005 была шутка-трудно установить и еще труднее поддерживать TFS2008 был стабильным-проще в установке, проще в обслуживании и автоматизированных сборках, которые работают. TFS2010-это эпично! - установка собака eassssyyy. Управление очень простое; это все красиво выложенный пользовательский интерфейс. Интеграция его с VS2008 не так просто, так как вы не можете создавать проекты в vs2008 вы должны использовать vs2010 (что глупо). TFS2010 также позволяет изменить расположение проекта sharepoint вместо того, чтобы иметь эти ужасные подпапки TFS2008. TFS2010 также имеет такие инструменты, как график выгорания, который действительно полезен для управления проектами. Это как TFS2010 для всей производственной команды, включая клиентов! Это все еще стоит слишком много, хотя: (

также имейте в виду, что TFS требует намного больше лошадиных сил от серверного оборудования. И как минимум одна лицензия windows server конечно.

Лучшая практика, как следует из нашей компании, заключается в использовании 2 серверов: front-end (со встроенным sharepoint) и выделенный sql-сервер в фоновом режиме (мы используем корпоративный кластер). TFS может быть установлен на 1 машине, но не должны.

в сравнении, наш сервер svn установлен на виртуальный сервер linux с 256 МБ оперативной памяти и 1 ЦП, и еще несколько раз быстрее при выполнении общих задач, таких как проверка-все. Виртуальное оборудование было самым низким vshpere мог назначить! Диск быстрый, хотя (SAN).

Я бы предположил, что TFS требует выделенного оборудования для по крайней мере $5000, в то время как сервер svn (на linux) может работать с любым оборудованием, которое устарело для текущей ОС на базе windows.

на мой взгляд, это зависит от ситуации и среды, в которой проект осуществляется. Если у вас есть только простой, небольшой проект, то SVN-это здорово. Как уже писали некоторые, VisualSVN прекрасно интегрируется в Visual Studio s.t. вам не нужно выполнять проверку/проверку через собственную файловую систему.

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

мы небольшая команда в процессе перехода от SVN к TFS2010. Наша самая большая причина сделать это-интеграция в Visual Studio и WebAccess для отслеживания ошибок, который теперь является частью TFS.

@Adam: надеюсь, у нас будет лучший опыт. Пока не могу сказать...

Я использовал SVN в последние 3 года (исходя из VSS ранее) и недавно пришлось переключиться на TFS2010. Общее ощущение заключается в том, что он Баггер, чем SVN, и за исключением хорошей интеграции с задачами/ошибками я не вижу в нем преимущества перед SVN. Скорость, кажется, также несколько медленнее, чем с SVN.

Если бы я выбрал sourcecontrol сейчас, я бы все равно пошел с SVN.

Что касается инструментов: - Ankhsvn Visual Studio плагин так же хорошо, как источник TFS управление - Черепаха намного лучше, чем аналог TFS

TFS отлично подходит, если вам не нужны не-разработчики, чтобы добраться до материала pm.

наша служба поддержки должна быть вовлечена в процесс, и это просто не сокращало его.

также управление сборкой в tfs 2005, по крайней мере, является attrotious, и он даже не может построить vs 2008 slns. Мне действительно не нравится, что мой выбор системы управления версиями влияет на мои варианты развертывания, поэтому моя команда не является магазином svn.

Если это просто на основе системы управления версиями, я бы пошел с SVN. Бесплатная надстройка AnkhSVN для Visual Studio была значительно улучшена в своем новом выпуске. Кроме того, вы получаете исходный код для SVN и документацию отлично! Они изменились какие-то мудреные вещи в системе управления версиями TFS 2010, и без исходного кода это может быть очень сложной задачей для устранения неполадок. Кроме того, вы зависите от команды MSDN для откачки документов, и они делают это самостоятельно график и на собственной глубине.

Это, как говорится, TFS, очевидно, предлагает гораздо больше, чем управление версиями. Это ALM. Объединение его с рабочими элементами, отчетностью, автоматизированными сборками,gated в, автоматизированного тестирования и т. д. может обеспечить некоторое очень богатое значение, которое вы можете получить только при подключении разрозненных инструментов с SVN. И, конечно же, наличие источника для SVN не является безотказным. Я попал в сценарии с SVN, где он все равно потребовались бы недели, чтобы полностью понять, что происходит.

Итак, я рекомендую вам взглянуть на это с точки зрения ALM и посмотреть, будет ли ваша компания использовать все функции TFS или собирается с лучшей в своем роде стратегией (например, JIRA).

TFS на милю.

Я непреднамеренно вызываю слишком много проблем для себя с подходом на основе файлов SVNs. Проблемы управления исходным кодом стихи: Проблемы TFS-0 за 2 года SVN-сбился со счета...

Да, я знаю, что цена TFS влияет на нее для большинства компаний, что является таким позором. MS могла бы иметь гораздо больше доли рынка (и прибыли), если бы у них была разумная модель ценообразования.