Каким образом Mercurial лучше/хуже, чем TFS?

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

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

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

Ответ 1

Вы не можете напрямую сравнивать TFS и DVCS.

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

В чистой версии Version-Control, Team Foundation Server 2010 с его Team Foundation Version Control (TFVC) 2010, вводит < сильные > ветки как первоклассный гражданин.
См. Team Foundation Server и характеристики ветвления по сравнению с другими.

Я все еще считаю, что их ветвящиеся модели более сложны, чем Mercurial или Git.
См. TFS2010 Ветвление в подпапку другой ветки против Руководство по модели ветвления в Mercurial (и этот вопрос SO, который также детализирует слияние и ветки с DVCS)

Таким образом, он остается CVCS (централизованный VCS), то есть вы получаете разные рабочие процессы, чем с DVCS: см. Опишите свой рабочий процесс с использованием управления версиями (VCS или DVCS).

Функция истинного убийцы DVCS остается ее способностью слияния (проще и быстрее, чем любой CVCS). Но внедрение DVCS в корпоративной среде остается трудным.

Ответ 2

Я рекомендую Joel on Software http://hginit.com список очень хороших причин для переключения на распределенное управление версиями.

Ответ 3

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

TFS очень сложно использовать вне Visual Studio. Даже разные версии выполняются внутри VS. Лично мне только нравится использовать VS для написания кода.
У нас было много проблем с dll и другими двоичными файлами, не обновляющимися до последней версии.
TFS делает все ваши файлы под контролем версий только для чтения. Это значительно облегчает изменение файлов вне VS очень. Фактически, это все еще вызывает проблемы с проектами Silverlight в нашей сборке непрерывной интеграции в TFS.
Инструмент командной строки для TFS нелегко использовать из командной строки. (Лично мне нравится использовать командную строку)

Фон: Моя компания переключилась с SVN и TFS, и я использую Mercurial/ Git для своих побочных проектов. Я также последовал за этим блоком об использовании Mercurial с TFS, и это сделало мою работу с TFS более приятной.

Ответ 4

TFS - это инструмент управления приложениями Lifecylce, а не только репозиторий/система управления версиями исходного кода.

Сила:

-It natural integration into Visual Studio (+100)
-It Full App Lifecycle support from Work Item through Q/A acceptance.
-It integration with MS Project / Sharepoint, and all the other 
 hoo-ha you get 
-And now TFS 2012 has added support for "Local Workspaces" which allows
  for off-line working, but also allows "Server Workspaces" which is 
  similiar to TFS 2010. 
-Diff on every Check-in / Commit

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

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

Теперь, несколько дней, чтобы профессионально работать с Mercurial (BitBucket/Mercurial/tortoiseHG/VisualHG), я должен сказать, что инструменты кажутся немного устаревшими. Интеграция с Visual Studio похожа на теплый кофе luke (ho-hum), и интеграция проводника возвращает меня к "хорошим дням", когда мне посчастливилось НЕ работать над Visual Source Safe.

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

Я определенно предвзято работаю с инструментами MS в течение долгого времени, но не так много для контроля источника, пока это работает.

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

Начните с управления версиями, закончите со спецификациями, созданными в MS Project, привязанным к работам, привязанным к Unit Test, привязанным к приемочным испытаниям, связанным с автоматическими сборками и развертываниями

И наконец: графики сжигания/скорости