SVN против Team Foundation Server

Ответ 1

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

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

Ответ 2

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

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

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

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

Мое мнение, за что это стоит:

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

3) Если вам нравится идея интеграции учетных записей с Windows Authentication, перейдите в 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 и дать ей повод. Проведите пробную версию бок о бок. Я думаю, вы будете счастливы, независимо от того, куда вы идете.

Ответ 6

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

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

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

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

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

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

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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

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

Ответ 9

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

Ответ 10

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

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

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

Ответ 11

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

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

• Tortoise Его черепаха, достаточно сказанная.

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

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

Ответ 12

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

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

Ответ 13

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

Ответ 14

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

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

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

Ответ 15

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

Ответ 16

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

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

Адам

Ответ 17

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

Модель регистрации/выписки

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

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

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

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

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

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

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

Ответ 18

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

Ответ 19

Мои 10 центов:

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

Ответ 20

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

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

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

Я бы предположил, что TFS требует специального оборудования по крайней мере 5000 долларов, в то время как svn server (on linux) может работать с любым оборудованием, которое устарело для текущих окон на основе os.

Ответ 21

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

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

Ответ 22

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

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

Ответ 23

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

Если бы теперь я должен был выбрать sourcecontrol, я бы по-прежнему работал с SVN.

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

Ответ 24

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

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

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

Ответ 25

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

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

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

Ответ 26

TFS на милю.

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

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