SVN против Team Foundation Server

Несколько месяцев назад моя команда переключила управление исходным кодом с Visual SourceSafe на Apache Subversion , и мы не стали счастливее.

Недавно я посмотрел на Team Foundation Server , и, по крайней мере, на первый взгляд, он кажется очень впечатляющим. Существует отличная интеграция с Visual Studio и множество отличных инструментов для администраторов баз данных, тестировщиков, менеджеров проектов и т. Д.

Самая очевидная разница между этими двумя продуктами - цена. Трудно превзойти Apache Subversion (бесплатно). Team Foundation Server стоит довольно дорого, поэтому дополнительные функции действительно должны бросить Subversion в упор.

  • Есть ли у кого-нибудь практический опыт работы с обоими?
  • Как они сравниваются?
  • Действительно ли Team Foundation Server стоит своих затрат?

Ответов (25)

Решение

Недавно я присоединился к проекту с открытым исходным кодом в CodePlex. Они используют TFS для управления версиями, и я должен сказать, что это просто великолепно. Пока что я невероятно впечатлен этим. Я большой поклонник интеграции IDE и того, как легко разветвлять и помечать код. Добавление решения в систему управления версиями - это что-то вроде двух щелчков мышью, если у вас уже все настроено правильно.

Теперь. Стоит ли такой дорогой ценник? Я так не думаю. Преимущество работы над проектами в CodePlex заключается в том, что это позволяет мне получить необходимый мне опыт работы с TFS на тот случай, если мне придется использовать его где-нибудь позже. Если вам нужна хорошая интеграция IDE для вашего Source Control, возьмите пакет интеграции VisualSVN . Это гораздо более дешевое вложение, чтобы получить множество тех же функций (бесплатно на компьютерах, не принадлежащих домену, BTW).

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

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

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

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

1) TFS довольно тесно связана с "способом разработки Visual Studio". Это не означает, что TFS тесно связана с VS IDE, это означает, что TFS изо всех сил пытается сохранить знакомую парадигму «проверка на входе» / «проверка» в Visual SourceSafe, даже если она действительно больше не является подходящей моделью. Концепция Subversion о «фиксации» / «обновлении» намного более реалистична, когда у вас есть разработчики, которые могут проводить время без подключения к сети. TFS ожидает, что разработчики всегда будут подключены к серверу. Это большой минус. Я лично считаю, что TFS не совсем прозрачна в отношении организации файлов на сервере и на вашем локальном диске из-за тесной интеграции с Visual Studio. Даже более крупные сторонники TFS признают, что ее подключенная модель регистрации / возврата не является привлекательным вариантом для разработчиков, которые работают автономно.

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

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

Мое мнение, чего стоит:

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

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

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

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

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

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

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

Если бы я сейчас выбрал источник управления, я бы все равно выбрал SVN.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Слияние - это БОЛЬ по сравнению с подрывной деятельностью.
  • Есть не исправленные ошибки. Я столкнулся с проблемой переименования / слияния, которая была известна уже 2 года, и исправление никогда не будет выпущено для 2005 года. В итоге мы переместили нашу ветку в «сломанную» папку и теперь игнорируем ее.
  • Установка блокировок только для чтения на ваши файлы - это трение. Кто сказал, что мне нужно редактировать командные файлы и создавать сценарии внутри TFS, чтобы он «проверил» это за меня? Subversion знает, какие файлы были изменены. Там нет блокировок только для чтения.
  • Скорость. TFS работает очень медленно в глобальной сети, и ее можно использовать только в том случае, если я подключаюсь к своему рабочему компьютеру через VPN, что в целом сильно замедляет мою работу с разработчиками.
  • Отсутствие хорошей интеграции с командной строкой и проводником. Интеграция IDE действительно хороша для повседневного использования Get-Latest, добавления файлов и проверки, но когда вам нужно что-то делать в рамках многих проектов, хорошо иметь в вашем распоряжении хорошие инструменты. И прежде, чем кто-то прыгнет мне в глотку, утверждая, что tf.exe работает хорошо ... это не совсем инструмент командной строки. Например, при проверке кода не должно открываться модальное диалоговое окно.

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

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

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

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

Также согласно сообщению Бена С. Я не понимаю ваш комментарий о замках. Блокировки в TFS вообще не требуются. Администраторы могут настроить TFS для работы как VSS (функции, требуемые некоторыми «неразумными» клиентами) до «Get-Latest on Checkout», что, как я полагаю, также блокирует извлечение.

Но при «нормальном» использовании TFS при «извлечении» пользователю предлагается указать тип блокировки, а значение по умолчанию должно быть «none». Пользователь МОЖЕТ выбрать регистрацию отъезда (или блокировку регистрации), но это не обязательно. Если вам не нужны замки, не используйте их.

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

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

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

Еще одна особенность, которую следует учитывать поклонникам SVN, использующим TFS, - это SVN Bridge - кодовый комплекс, который позволяет пользователям использовать TortiseSVN для подключения к TFS. Мой хороший друг и коллега активно пользуется им, и он мне очень нравится.

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

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

Как отмечали другие, 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, Eclipse и т. Д.), Используйте SVN. Да, есть очень хорошие продукты (например, Teamprise), которые хорошо работают с TFS. Но если другие языки не являются небольшой частью вашего магазина, просто придерживайтесь SVN.

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

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

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

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

  1. VisualSVN Server Это полноценный SVN-сервер с хорошим плагином для управления им. Он позволяет использовать проверку подлинности Windows прямо через пользовательский интерфейс. Легкий.

  2. Черепаха Это уже черепаха.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Адам

Мои 10 центов:

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

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

Модель заселения / выселения

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

VS требуется для всего

Иногда я хочу отредактировать текстовый файл и зарегистрировать его. Это требует, чтобы я запустил VS 2010, который является огромным зверьком, просто чтобы отредактировать файл и зарегистрировать его. То, что заняло несколько секунд с SVN, теперь занимает у меня минуту .

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

Некоторые операции, которые были простыми в SVN, теперь стали проблемой

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

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

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

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

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

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

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

Для сравнения, наш svn-сервер установлен на виртуальном Linux-сервере с оперативной памятью 256 МБ и 1 процессором, и он по-прежнему на несколько порядков быстрее при выполнении обычных задач, таких как проверка всех. Виртуальное оборудование было самым низким вшпере, которое только можно было назначить! Диск работает быстро (SAN).

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