SVN против Team Foundation Server [закрыто]

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

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

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

  • У кого-нибудь есть практический опыт работы с обоими?
  • Как они сравниваются?
  • Действительно ли Team Foundation Server стоит таких затрат?
7.08.2008 00:43:33
26 ОТВЕТОВ
РЕШЕНИЕ

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

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

46
17.08.2012 16:06:33
встроить tfs, не очень хорошо, даже если вы используете его, я рекомендую запускать круиз-контроль в тандеме, чтобы вы могли быть на самом деле независимы от управления исходным кодом. (то есть tfs 2005, не будет создавать решения против 2008)
DevelopingChris 8.09.2008 18:51:04
@ChanChan: Управление сборкой TFS 2008 неплохое. Однако управление сборкой в ​​2005 году было шуткой.
Dave Markle 18.02.2009 01:09:03
Я рекомендую использовать AnkhSVN, это хороший плагин управления исходным кодом для Subversion и работает точно так же, как и с использованием TFS ... за исключением рабочих элементов и тому подобного, которые, конечно, не являются частью Subversion.
galaktor 28.08.2009 21:15:29
@Jeremy - Какую функциональность в TFS вы использовали для маркировки своего хранилища (из цитаты: «... как легко разветвлять и маркировать код.»)?
Russell 15.10.2009 03:44:43
Средства управления исходным кодом TFS ужасны по сравнению с SVN, вы не можете делать почти ничего, кроме самых простых вещей, не используя «powertools» (откат изменений - это «мощная» вещь ??), которые не интегрированы в VS. Все говорят, что TFS великолепен и все такое, и из того, что я видел, похоже, что это верно для сервера, но клиентские инструменты ужасны.
Eduardo Scoz 15.10.2009 13:56:20

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

3
7.08.2008 05:28:18

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

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

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

8
23.05.2017 12:16:59

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

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

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

3
29.08.2008 10:08:08
Bugzilla это ужасно! Не рекомендую это!
Orion Edwards 2.02.2009 20:41:30
Да, вместо этого рекомендую FogBugz, это довольно хорошо.
Jeremy Friesner 3.05.2010 19:14:13

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

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

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

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

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

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

48
3.02.2010 08:17:13
У нас есть TFS для выполнения ветвления и слияния, и это был кошмар. В настоящее время мы смотрим на SVN.
Brian MacKay 18.09.2008 16:34:47
«Слияние - это боль по сравнению с подрывной деятельностью». - Почему вы так думаете? Я перешел с TFS на SVN с AnkhSVN и TortoiseSVN, и это было все неприятные сюрпризы. Можете ли вы указать на концептуальные различия между двумя модулями?
Slavo 7.08.2009 10:11:35
SVN кажется более умным в отношении того, что можно безопасно объединить автоматически, и это обычно тот тип объединения, с которым мне приходится иметь дело. Например, 2 пользователя добавляют файлы в один и тот же файл проекта. Если 2 человека добавляют методы в файл в разных областях, автоматическое объединение также работает хорошо. Если вы изменяете то же местоположение, тогда должен включаться инструмент слияния. В зависимости от того, какой инструмент слияния вы используете, это может быть жесткий или средний (или легкий, если у вас Beyond Compare). Взять эту строку, эту строку, сохранить файл, разрешить конфликты, готово.
Ben Scheirman 10.08.2009 21:14:46
Я не согласен по поводу слияния SVN. Существуют известные проблемы, если файлы были отредактированы как в ветке, так и в стволе, когда вы пытаетесь выполнить слияние ветки и ствола. В прошлом году мы провели выходные в офисе, выполняя очень сложное слияние вручную. При этом я понятия не имею, лучше или хуже TFS. Мне также интересно, почему не появился золотой стандарт профессионального управления версиями Perforce.
Steve Severance 5.11.2009 01:40:18
Хм, нет, извини. Я считаю себя достаточно компетентным в других системах контроля версий, поэтому комментировать отсутствие SOC совсем не правильно. В прошлый раз, когда я проверял, файлы решений / проектов меняются ВСЕМИ ТОЛЬКО О КАЖДОЙ ПРОВЕРКЕ. TFS должен иметь возможность обрабатывать слияния в этих файлах с завязанными глазами. Тем не менее, (в TFS 2005) у меня были почти ежедневные проблемы с этим. Это инструмент. Попробуйте все, кроме TFS, и вы будете знать. 2010 год может быть лучше, но зачем ждать? Git был тверд для меня с
Ben Scheirman 23.08.2010 20:02:53

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

8
27.05.2010 19:26:31
Я согласен! Я пробовал это раньше, и он был глючит по сравнению с сейчас. Это действительно круто.
EnocNRoll - Ananda Gopal 17.02.2009 17:00:01

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

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

4
29.08.2008 21:27:14

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

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

Но при «обычном» использовании TFS «check-out» запрашивает у пользователя тип блокировки - и по умолчанию должно быть «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 в ближайшем будущем.

16
7.09.2008 13:31:52
Больше не трата денег, когда клиент и сервер TFS теперь БЕСПЛАТНЫ с каждой копией MSDN!
MrHinsh - Martin Hinshelwood 21.08.2010 14:59:35
Но это было верно в сентябре 2008 года, когда я написал (но хорошее обновление, Мартин!)
fuzzbone 1.04.2011 19:25:50

Как уже отмечали другие, 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 в обоих случаях примерно одинаковы. Они оба выполняют ветвление и объединение, оба выполняют атомарную регистрацию, они оба поддерживают переименования и перемещения. Я думаю, что для людей, только начинающих работать с концепцией ветвления и слияния, хорошо видеть ветки в Source Control Explorer.

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

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

23
7.09.2008 14:00:04
многое из этого не совсем верно - конечно, я использую TortoiseSVN, когда могу, но только потому, что он так хорош, это мой инструмент первого выбора, даже когда у меня установлен AnkhSVN. SVN успешно занимается интеграцией ADS - просто используйте VisualSVN Server. Многие, многие отличные средства отслеживания ошибок или инструменты PM легко интегрируются с SVN и превосходят функции управления TFS. Политики регистрации очень просты в SVN, просто установите хук перед фиксацией, он даже поставляется с примерами и имеет много других хуков, которые вы можете использовать, а TFS - нет. Но .... пункт 5, вероятно, является наиболее важным.
gbjbaanb 14.08.2013 12:33:24

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

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

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

7
9.01.2011 20:52:44

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

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

  2. Черепаха Своя черепаха, достаточно сказано.

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

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

6
8.09.2008 18:46:37

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

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

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

0
8.09.2008 18:49:55

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

3
16.09.2008 16:06:08

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

2
22.09.2008 02:48:39
Это потому, что ClearCase может быть худшей системой контроля версий, которую когда-либо будет использовать большинство людей.
Steve Severance 5.11.2009 01:43:26
Мало того, что лицензирование для Clear Case и других рациональных инструментов просто смешно!
MrHinsh - Martin Hinshelwood 21.08.2010 15:03:52

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

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

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

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

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

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

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

87
15.09.2011 17:44:19
Это именно та информация, которую я искал, спасибо.
EnocNRoll - Ananda Gopal 17.02.2009 16:24:14
... «TFS также выигрывает, когда вам нужно централизованно применять политику в ваших проектах». +1. Это огромно, когда приходится иметь дело с различными наборами навыков разработчиков в магазине
StingyJack 3.05.2010 19:16:33
+1 за "все еще жду действительно хорошего трекера проблем OSS" - я тоже ...
BlueRaja - Danny Pflughoeft 23.06.2010 18:30:06
С запуском Visual Studio 2010 MSFT включил как клиентские, так и серверные лицензии с MSDN. Так что, если у вас есть MSDN для всех ваших разработчиков, они будут БЕСПЛАТНЫМИ, а ваш TFS-сервер БЕСПЛАТНЫМ. Кроме того, бизнес-пользователям больше не нужна лицензия для создания рабочих элементов и просмотра созданных ими рабочих элементов. Если у вас есть до 5 бизнес-пользователей, которые хотят получить доступ к TFS, вы можете купить розничную лицензию TFS Server за 500 долларов США, которая позволяет 5 пользователям без клиентской лицензии. Но дополнительные пользователи не-MSDN обойдутся вам в 300 долларов за лицензию CAL.
MrHinsh - Martin Hinshelwood 21.08.2010 14:55:27
3) Структура проекта: в TFS 2010 вы можете отказаться от этой неприятности для небольших команд. Просто установите с помощью базовой установки, и вы получите рабочие элементы с контролем версий без Sharepoint ...
MrHinsh - Martin Hinshelwood 21.08.2010 15:09:39

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

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

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

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

10
18.08.2009 15:55:20

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

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

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

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

43
17.08.2012 16:07:55
То же самое с NUnit и Sharepoint вместо Bugzilla.
boj 19.01.2010 19:45:41
то же самое здесь, за исключением bugtracker.net на Nr 1.
Johan Wikström 25.01.2010 10:04:21
То же самое и с TeamCity в качестве сервера сборки. Бесплатно до 20 проектов.
ThiagoPXP 13.04.2012 05:56:08
VisualSVN 3.0 предоставляется бесплатно на компьютерах, не входящих в домен (лицензия сообщества), поэтому AnkhSVN - не единственный «бесплатный» вариант :)
bahrep 17.08.2012 16:03:22

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

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

1
14.08.2009 21:17:30

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

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

Адам

3
5.11.2009 01:52:16
Многие из вас исправлены в TFS 2010, но TFS по-прежнему является «проверочной» системой, поэтому, если вы не скажете TFS, что, по крайней мере, собираетесь изменить файл, он не проверит его на сервере. Вам бы понравилось, если у вас есть миллионы файлов в системе контроля версий, но я чувствую боль для небольших проектов.
MrHinsh - Martin Hinshelwood 21.08.2010 15:03:13

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

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

1
23.03.2010 14:00:33

Мои 10 центов:

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

2
23.06.2010 18:23:30

TFS на милю.

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

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

-3
8.12.2010 03:42:46
Какие проблемы? Как это связано с файловым подходом?
Sean McMillan 7.07.2011 14:08:38
Я использую SVN в течение 7 лет. и абсолютно никаких проблем не обнаружено.
pylover 10.04.2012 03:56:15

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

Модель заезда / отъезда

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

VS обязан делать все

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

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

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

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

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

3
21.12.2010 12:36:21
Откат должен быть сделан в командной строке. msdn.microsoft.com/en-us/library/dd380776.aspx
LeWoody 7.02.2011 18:39:26

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

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

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

0
7.02.2011 18:36:06

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

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

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

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

2
20.04.2011 18:01:32

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

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

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

1
4.04.2012 17:50:15