version control - software - ¿De qué manera es Mercurial mejor/peor que TFS?

sql server versioning control

Question

Me acabo de unir a una nueva empresa y en este momento estamos usando Microsoft SourceSafe como nuestro repositorio. La configuración no es ideal y está demostrando ser un gran dolor en el cuello.

Recientemente utilicé Mercurial y pensé que era increíble, por lo que abogo por cambiar a eso, pero parece que la compañía ya tiene una licencia de Team Foundation Server y quiere usarla en su lugar.

¿Alguien puede darme una lista de puntos donde uno es mejor que el otro? No he usado TFS y, por lo tanto, no sé qué es bueno / malo.

Answer 1

He encontrado algunos errores con TFS que lo hacen un poco diferente a otros CVCS.

• TFS es muy difícil de usar fuera de Visual Studio. Incluso las diferentes versiones se hacen dentro de VS. Personalmente solo me gusta usar VS para escribir código.
• Hemos tenido muchos problemas con archivos 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 la modificación de archivos fuera de VS sea muy dolorosa. De hecho, esto sigue causando problemas con nuestros proyectos Silverlight en nuestra compilación de integración continua 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)

Antecedentes: mi empresa cambió de SVN y TFS y utilizo 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.

Answer 2

No puede comparar directamente TFS y un DVCS.

Si su empresa se inclina por TFS, eso puede deberse a las otras características que TFS incluye (recopilación de datos, informes y seguimiento de proyectos, todos bien integrados con los productos de Microsoft)

Por el lado del control de versiones puras, Team Foundation Server 2010 , con su Team Foundation Version Control (TFVC) 2010, presenta a las sucursales como ciudadanos de primera clase .
Ver Team Foundation Server y las características de ramificación, en comparación con otras .

Todavía encuentro sus modelos de derivación más complejos que uno de Mercurial o Git.
Consulte TFS2010 Ramificación en una subcarpeta de otra rama en comparación con la Guía para el Modelo de Ramificación en Mercurial (y esta pregunta SO, que también detalla las fusiones y ramas con DVCS)

Dicho esto, sigue siendo un CVCS (VCS centralizado), lo que significa que obtiene diferentes procesos de trabajo que con un DVCS: consulte Describa su flujo de trabajo de uso del control de versiones (VCS o DVCS) .

La verdadera característica asesina de un DVCS sigue siendo su capacidad de combinación (más simple y más rápida que cualquier CVCS). Pero introducir un DVCS en un entorno corporativo sigue siendo difícil .

Answer 3

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

Answer 4

TFS es una herramienta de administración de Lifecylce de aplicaciones que NO SOLO es un repositorio de código fuente / sistema de control de versiones.

Sus puntos fuertes son:

-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 de control de la Fuente también es muy fuerte, sin embargo, personalmente, siempre que pueda ver todo el historial, no pierda el código y no tenga mi código "pisado". Podría dar una maldición.

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

Ahora, después de unos días de trabajar con Mercurial profesionalmente (BitBucket / Mercurial / tortoiseHG / VisualHG), debo decir que las herramientas parecen un poco anticuadas. La integración con Visual Studio es como el café tibio (ho-hum), y la integración del explorador me lleva de nuevo a "los buenos tiempos" cuando tuve la suerte de NO estar trabajando en Visual Source Safe.

Otra cosa a tener en cuenta es la facilidad de migrar de Visual Source Safe a TFS, es bastante sencillo ... recientemente cambié el historial completo de mi última compañía en VSS a TFS y solo tomé un par de utils de línea de comandos y de la noche a la mañana para obtener todo el la historia del cambio se movió Me sorprendió (como a mis colegas) lo fácil que era la migración, incluso conservó toda la historia desde el principio (a petición de los poderes).

Definitivamente estoy predispuesto a haber trabajado con herramientas de MS durante mucho tiempo, pero no hay mucho para controlar la fuente, siempre y cuando funcione.

Si su organización desea administrar verdaderamente 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 Source Control, termine con especificaciones originadas en MS Project, vinculadas a elementos de trabajo vinculados a la prueba de unidad vinculados a pruebas de aceptación vinculadas a compilaciones y implementaciones automatizadas

Y por último: Grabar / Velocity Gráficos