Должны ли мы перейти от svn к Team Foundation Server 2010?

Ответ 1

Если вы являетесь магазином Microsoft, тогда TFS хорошо подходит.

Если Subversion делает все, что вам нужно, вы бы исправили что-то, что не сломалось?

У вас должна быть причина для изменения.

[Я использую TFS на работе, и он отлично работает, с очень небольшим количеством проблем. Я использую Subversion дома, просто потому, что мне нужна меньше инфраструктуры].

Update [2012/05/01]: Если вы не являетесь магазином Microsoft, тогда Git и mercurial теперь станут инструментами выбора.

Ответ 2

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

Ответ 3

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

Я перешел от работы с SVN на предыдущем задании до TFS на более поздней работе. Я бы подвел итог следующим образом:

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

Подробнее:

Исходная система управления, технически очень хорошая на сервере и т.д., PAINFUL используется. Файлы всегда маркируются только для чтения, и вы должны явно их проверять, чтобы редактировать их. Это делает вашу жизнь ужасной, если вы не используете визуальную студийную интеграцию в 100% случаев... И если вы используете интеграцию с визуальной студией, помните, что она хранит статус SCC всех ваших файлов в файле CSPROJ FILE, так что подготовленный к случайным путаницам и неудачам, потому что вы добавили файл в TFS, но визуальная студия этого не осознала (или наоборот).

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

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

Кроме того, TFS имеет очень тесную интеграцию с вашим доменом. Если 100% ваших сотрудников и все ваши сборки/тестовые машины находятся в одном домене, то это, вероятно, хорошо... но если вы этого не сделаете, это приведет к некоторой боли.

Ответ 4

SVN управляет источником. Его клиентом по умолчанию является командная строка, но существуют инструменты GUI.

TFS контролирует источник, отслеживает ошибки/проблемы, автоматизирует сборку, создает отчеты для менеджеров и может вылечить облысение мужского пола. Его клиентом по умолчанию является Visual Studio.

Если все, что вам нужно, это управление источником, то SVN работает, и зачем менять то, что не сломано. Если все, что вам нужно, - это более тесная интеграция в Visual Studio, затем посмотрите Ankh или VisualSVN.

Если вам нужны автоматические сборки, непрерывная интеграция, проверка политик и правил, отчетность, отслеживание проблем, и вы хотите, чтобы все это было в одном, то TFS для вас - если вы не выходите за пределы средств разработки Microsoft (обычно - там являются плагинами для других IDE). Вы можете получить то же самое с другими инструментами FOSS и обернуть их вместе с липкой лентой вокруг SVN, и это тоже работает, это просто не так просто и требует немного больших инвестиций.

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

Ответ 5

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

В Интернете есть обзоры, которые не принадлежат маркетологам MS, которые показывают, что TFS - это не лучшая вещь с git. Мартин Фаулер survey для одного очень интересный (из 54 ответов, ни один не думал, что это здорово или даже хорошо). Может быть, его читатели менее увлекаются инструментами "полного жизненного цикла", чем большинство разработчиков, но, может быть, они такие же, как и у всех нас. Аналогичные обзоры доступны, в том числе статья Forrester Research (которую я прочитал: резюме, SVN - это "победа" автономных SCM)

Итак, только потому, что TFS теперь включен в VS, он не делает его лучшим. Перед переключением необходимо правильно оценить его.

Ответ 6

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

Ответ 7

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

Ответ 8

Я думаю, что TFS фантастичен. Слежение за ошибками и контроль исходного кода, полностью интегрированный с Visual Studio, - большая экономия времени. Протокол on-wire не слишком чат, поэтому он также подходит для работы через Интернет, если это необходимо.

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

Они также имеют полную поддержку командной строки для сценариев, автоматических сборок, автономного клиента TFS для использования вне Visual Studio (скажем, не-разработчиками) и дополнительной интеграции со сторонними инструментами, такими как Eclipse для смешанной Java/. NET.

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

Ответ 9

Если вы используете его только для контроля версий, придерживайтесь SVN. Если у вас есть решения Linux/Java, придерживайтесь SVN. Если вы только MS и вам нравятся рабочие элементы для отслеживания требований/ошибок и т.д. (Что мне нравится), подумайте о переходе на TFS, но помните, что вам нужно будет запланировать CAL, чтобы люди могли получить доступ к этой информации. Если вы хотите, чтобы ночное тестирование/сборки CI не учитывали дополнительные лицензии VS для вашего сервера сборки, поскольку teambuild (msbuild) не может создавать проекты VDProjs, Intel и т.д.

также... TFS 'кажется'/'появляется', чтобы бороться с некоторыми действительно основными вещами, например. как игнорировать файлы, которые вы не хотите помещать в репозиторий, и он часто помещает файлы как измененные, что diff показывает как идентичные.

Ответ 10

Это скорее психологический, чем технический вопрос.

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

VisualSVN - хороший инструмент, который позволяет вам "интегрировать" достаточно. И он будет улучшен еще лучше.

Ответ 11

Хотя this может помочь вам принять решение; Я согласен с Митчем. У вас есть все основания для изменения. SVN является более зрелым и надежным, чем TFS. Кроме того, TFS в первую очередь ориентирована на приложения Microsoft, по сравнению с областью SVN, которая выходит за пределы TFS.

Ответ 12

У меня был TFS у моего последнего клиента, теперь у моего нового клиента есть подрывная деятельность, и это ужасно. Нет стеллажей - настоящий убийца.

Я упоминал об этом бесплатно с VS 2010

Ответ 13

Я использовал как TFS 2010, так и SVN (с Tortoise), Mingle, MediaWiki и т.д.

Несмотря на то, что TFS дает вам интеграцию стиля "Исходный безопасный" с Visual Studio, то, где заканчиваются тонкости. SVN намного лучше контролирует контроль версий, Mingle - это ослепительно лучший инструмент для совместной работы, а MediaWiki - гораздо лучшая вики.

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

Ответ 14

Когда я работаю, группа перенастраивается на TFS из DOORS в основном для требований, спецификаций и т.д. Они по-прежнему используют Perforce в качестве репозитория. Я использовал большинство репозиториев там, и у каждого есть свои собственные причуды.

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