¿De qué manera Mercurial es mejor / peor que TFS? [cerrado]

Recomiendo Joel en Software http://hginit.com para una lista de muy buenas razones para cambiar al control de versiones distribuido.

He encontrado algunos puntos clave con TFS que lo hacen un poco diferente de otros CVC.

• TFS es muy difícil de usar fuera de Visual Studio. Incluso diffing versiones se hace dentro VS. Personalmente solo me gusta usar VS para escribir código.
• Hemos tenido muchos problemas con dll y otros archivos binarios que no se actualizan a la última versión.
• TFS hace que todos sus archivos bajo control de versiones sean de solo lectura. Esto hace que modificar archivos fuera de VS sea muy doloroso. De hecho, esto todavía está causando problemas con nuestros proyectos Silverlight en nuestra Integración Continua construida en TFS.
• La herramienta de línea de comandos para TFS no es fácil de usar desde la línea de comandos. (Personalmente, me gusta usar la línea de comandos)

Fondo: Mi empresa cambió de SVN y TFS y uso Mercurial / Git para mis proyectos paralelos. También seguí este blog sobre el uso de Mercurial con TFS y ha hecho que mi trabajo con TFS sea mucho más agradable.

TFS es una Herramienta de Gestión de Lifecylce de Aplicaciones no SOLO un repositorio de código fuente / sistema de control de versiones.

Su fuerza es:

-It's natural integration into Visual Studio (+100)
-It's Full App Lifecycle support from Work Item through Q/A acceptance.
-It's integration with MS Project / Sharepoint, and all the other 
 hoo-ha's 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

El lado del control de código fuente también es muy fuerte, sin embargo, personalmente, siempre y cuando pueda ver toda la historia, no perder código, y no tener mi código "pisado". Me importa un bledo.

He estado usando TFS desde 2008 y la última ronda de mejoras demuestra aún más los compromisos de Microsofts para desarrollar sus productos y mantenerse al día con los cambios de la industria. Personalmente me encanta, pero me quedo en el entorno de Microsoft (que también me encanta).. fuera de eso, puede que no funcione con las necesidades de todos.

Ahora, a los pocos días de trabajar profesionalmente con Mercurial (BitBucket / Mercurial / TortoiseHg / VisualHg ) , tengo que decir que las herramientas parecen un poco anticuadas. La integración con Visual Studio es como luke warm coffee (ho-hum), y la integración de explorer me lleva de vuelta a "los buenos días" cuando tuve la suerte de NO ser trabajando en la Fuente Visual Segura.

Otra cosa a tener en cuenta es la facilidad en la migración de Visual Source Safe a TFS, es bastante indoloro.. recientemente moví toda la historia de mis últimas compañías en VSS a TFS y solo me tomó un par de utilidades de línea de comandos y de la noche a la mañana para mover todo el historial de cambios. Me sorprendió (como donde mis colegas) lo fácil que fue la migración, incluso mantuvo toda la historia desde el principio (por solicitud de los poderes fácticos)

Estoy definitivamente sesgado haber trabajado con herramientas de MS durante mucho tiempo, pero no hay mucho para el control de código fuente, siempre y cuando funcione..

Si su organización quiere administrar realmente todos los aspectos del desarrollo de aplicaciones, y aún no tienen herramientas o procesos integrados, TFS les brindará la capacidad de crecer y administrar desde el principio.

Comience con el Control de código fuente, termine con especificaciones originadas en MS Project, atadas a elementos de trabajo atadas a Pruebas unitarias atadas a pruebas de aceptación atadas para compilaciones e implementaciones automatizadas

Y por Último: Quemar Abajo / Gráficos de velocidad