SVN против Team Foundation Server

голоса
74

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

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

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

  • Кто-нибудь имеет практический опыт работы с обоими?
  • Как они соотносятся?
  • Является Team Foundation Server на самом деле стоит затрат?
Задан 07/08/2008 в 01:43
источник пользователем
На других языках...                            


26 ответов

голоса
87

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

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

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

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

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

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

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

Ответил 25/10/2008 в 15:33
источник пользователем

голоса
48

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

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

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

Мои основные вопросы, с TFS:

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

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

Ответил 29/08/2008 в 21:19
источник пользователем

голоса
46

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

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

Ответил 07/08/2008 в 01:52
источник пользователем

голоса
42

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

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

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

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

Ответил 14/08/2009 в 22:11
источник пользователем

голоса
23

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

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

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

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

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

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

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

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

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

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

Ответил 07/09/2008 в 15:00
источник пользователем

голоса
16

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

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

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

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

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

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

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

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

Я подозреваю, что комментарии Бена основаны на Eval выпуска 2005 года, который был явно «Microsoft V1.0» продукт. Продукт в настоящее время 2,1 с версии 3 идет в ближайшем будущем.

Ответил 07/09/2008 в 14:31
источник пользователем

голоса
10

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

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

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

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

Ответил 14/08/2009 в 22:02
источник пользователем

голоса
8

Вот открытая версия источника VisualSVN называется AnkhSVN . Его гораздо лучше , что CollabNet взяла его.

Ответил 29/08/2008 в 21:51
источник пользователем

голоса
8

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

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

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

Ответил 17/08/2008 в 03:30
источник пользователем

голоса
7

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

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

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

Ответил 08/09/2008 в 19:35
источник пользователем

голоса
6

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

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

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

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

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

Ответил 08/09/2008 в 19:46
источник пользователем

голоса
4

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

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

Ответил 29/08/2008 в 22:27
источник пользователем

голоса
3

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

Заезд / модель Выселение

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

VS необходимо сделать все,

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

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

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

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

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

Ответил 21/12/2010 в 13:36
источник пользователем

голоса
3

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

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

Адам

Ответил 05/11/2009 в 02:52
источник пользователем

голоса
3

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

Ответил 16/09/2008 в 17:06
источник пользователем

голоса
3

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

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

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

Ответил 29/08/2008 в 11:08
источник пользователем

голоса
3

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

Ответил 07/08/2008 в 06:28
источник пользователем

голоса
2

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

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

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

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

Ответил 20/04/2011 в 19:01
источник пользователем

голоса
2

Мои 10 центов:

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

Ответил 03/05/2010 в 20:10
источник пользователем

голоса
2

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

Ответил 22/09/2008 в 03:48
источник пользователем

голоса
1

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

Если бы я был выбрать SourceControl сейчас я бы еще пойти с SVN.

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

Ответил 04/04/2012 в 14:49
источник пользователем

голоса
1

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

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

Ответил 23/03/2010 в 15:00
источник пользователем

голоса
1

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

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

Ответил 14/08/2009 в 22:17
источник пользователем

голоса
0

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

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

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

Ответил 07/02/2011 в 19:36
источник пользователем

голоса
0

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

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

Кроме того, управление сборки в TFS 2005 по крайней мере, attrotious, и он не может даже построить VS 2008 SLNS. Я действительно не нравится, что мой выбор системы управления версиями, влияет на мой выбор развертывания, поэтому моя команда не СВН магазин.

Ответил 08/09/2008 в 19:49
источник пользователем

голоса
-3

TFS на милю.

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

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

Ответил 08/12/2010 в 04:42
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more