Team Foundation Server против SVN и других систем управления версиями

В настоящее время мы ищем систему контроля версий для использования в наших проектах. В настоящее время наша команда составляет менее 10 человек. Мы используем VSS последние 5 лет. Я никогда не работал с SVN и другими системами управления версиями.

До сих пор мы использовали VSS, но в настоящее время существуют более мощные системы управления версиями, такие как TFS, SVN и т.д. Мы планируем перенести наши проекты в Visual Studio 2010, поэтому первая идея, которая приходит на ум, - начать использовать TFS 2010.

Мой вопрос: насколько хороша TFS по сравнению с другими системами управления версиями? Это хорошая идея, использующая его, или нам лучше использовать SVN (или любую другую систему)?

Ответ 1

Team Foundation Server - это полный пакет управления жизненным циклом приложений. Если у вас есть Professional, Premium или Ultimate версия Visual Studio 2010 с подпиской MSDN, Team Foundation Server 2010 теперь бесплатна. Все ваши пользователи Visual Studio, подпадающие под эту классификацию, также не требуют дополнительной лицензии CAL. Тем не менее, другим пользователям требуется, чтобы вы приобрели лицензии CAL, чтобы оставаться в силе с лицензией.

Используя Team Foundation Server 2010, вы получите исходный контроль, управление процессами, отслеживание дефектов, создание служб, отчетность, порталы проектов и многое другое. SVN строго контролирует исходный код. Я использовал оба, и они разные звери. Было бы справедливо сказать, что тип функций, предлагаемых SVN, является подмножеством Team Foundation Server в целом. Хотя есть сторонние коннекторы, чтобы упростить работу с SVN внутри Visual Studio (также, как я полагаю), встроенная интеграция между Visual Studio и Team Foundation Server довольно плавная. С административной точки зрения, как на уровне сервера, так и на уровне проекта, у вас отличный баланс простоты использования и возможностей.

В течение последних трех лет, между двумя разными работодателями, я установил и установил Team Foundation Server и поддерживал его на протяжении всей своей жизни. Обе компании использовали его в своих интересах, чтобы иметь возможность принести упорядоченный процесс в их SDLC. Шаблон MSF Agile v5, если вы являетесь магазином Agile/Scrum, является выдающимся. Планирование и управление Sprint никогда не было таким простым с любым инструментом, каким он есть сейчас.

Изменить - Добавлена информация о небольших командах:

Я заметил комментарий к вопросу о небольших командах. Team Foundation Server 2010, учитывая его цену, теперь имеет смысл для небольших команд. Однако я бы не рекомендовал его с Team Foundation Server 2008. В последней версии есть очень приятная "базовая" конфигурация, которая обеспечивает легкую установку, отсутствие отчетов и функциональность портала. Вы также можете установить его локально, если вы являетесь "магазином одного человека" с этой конфигурацией (Microsoft фактически перечисляет его как приемлемую конфигурацию для установки клиента). У меня есть это на моем ноутбуке для моей работы в POC - установив до ночного плана обслуживания и переноса моей резервной копии на Dropbox. Хорошо работает для спокойствия.; -)

Ответ 2

Работая с TFS, Git, Subversion, CVS и VSS, позвольте мне быстро обобщить мой опыт:

Справедливости ради следует сказать, что и Visual SourceSafe (VSS), и система параллельных версий (CVS) в наши дни довольно устарели.
Git является технически самым мощным инструментом, но для понимания понятий требуется некоторое время. Он также играет большую часть своих преимуществ только в том случае, если вы действительно используете распределенный подход scm. Количество сторонних программ, поддерживающих Git, быстро растет, но пока не столь распространено, как для SVN.
Subversion (SVN) предлагает чистые и понятные концепции с довольно общим и общим подходом. Доступно огромное количество программного обеспечения для интеграции большинства IDE и файловых менеджеров, а также множество программ для расширения. Из-за использования стандартных протоколов, таких как HTTP и WebDAV, он также интегрируется с программным обеспечением, которое на самом деле не предназначено для работы с SVN, например Microsoft Office ( "Windows Web Folders" ) и т.д. SVN будет моей рекомендацией, если вы планируете использовать более традиционный, централизованный подход SCM.
Контроль версий TFS тесно интегрирован с линейкой продуктов Microsoft Visual Studio и остальной частью платформы жизненного цикла разработки TFS. Для использования вне Visual Studio существует ряд инструментов и интерфейс командной строки, но, действительно, не имеет смысла использовать TFS без Visual Studio, поверьте. Управление версией TFS является технически одним из худших, с которыми я когда-либо работал. Причины:
- Требуется явная проверка каждого файла, с которым вы работаете. Тот же файл, который проверяется более чем одним человеком в то же время, означает, что TFS видит конфликт, независимо от того, действительно ли эти люди что-то изменили.
- TFS использует концепцию "рабочего пространства", где действия в вашей рабочей копии записываются на сервере по мере вашей работы. Вы не можете просто проверять несколько копий исходного дерева на несколько папок, вам нужно постоянное онлайн-соединение с сервером (есть режим "офлайн", но это все испортит). Все изменения на что-либо в локальной рабочей копии должны сначала проходить через клиентские инструменты TFS, так как файлы загружаются как только для чтения.
- Тот факт, что TFS показывает больше конфликтов в пользовательском интерфейсе, чем на самом деле, побуждает пользователей просто отказываться от массового принятия или отказываться от массового отклонения, что приводит к потере изменений в том или ином виде. Таким образом, это мешает вашему взгляду на то, что на самом деле важно, что опасно для системы контроля версий.
- Интеграция пользовательского интерфейса в VS не поддерживает много полезных операций, которые вам нужны при серьезной работе с системой SCM, например, создание атомных (только для сервера) ветвей, ветвление от более ранних версий, удаление, возврат изменений данного набора изменений, и многое другое.
- Это ужасно медленно, потому что создание ветки подразумевает загрузку всей новой копии исходного дерева, если это делается через VS GUI. Простое переименование папки также очень медленное. В целом, похоже, для простых операций создается много сетевого трафика.
- Встроенная функция "стеллажи", в которой вы можете сэкономить свои текущие изменения, не проверяя их, является хорошей идеей, но очень бесполезной в большинстве сценариев, поскольку она не поддерживает разрешение конфликтов или слияние, примените ваши полные изменения к своей рабочей копии. Если создание ветвей было таким же простым, надежным, быстрым и простым, как, например, в SVN вам не понадобится такая функция, поскольку каждый разработчик может создавать свои собственные ветки для управления этим требованием.
- В нашей среде в управлении версиями TFS появился ряд ошибок, где файлы, которые были фактически изменены, где они не были записаны как таковые, и в некоторых случаях файлы были возвращены к более ранней версии без уведомления. Это действительно не должно происходить в системе контроля версий!

Ответ 3

У Мартина Фаулера есть интересный пост об этой теме на его веб-сайте.