2010-11-05 63 views
25

Acabo de unirme a una nueva compañía y, por el momento, utilizamos Microsoft SourceSafe como nuestro repositorio. La configuración no es ideal y está demostrando ser un gran dolor en el cuello.¿De qué manera Mercurial es mejor/peor que TFS?

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

¿Alguien me puede dar una lista de puntos donde uno es mejor que el otro? No he usado TFS, así que no sé para qué sirve.

+7

Como nuevo empleado, no me gustaría perder el tiempo intentando que el equipo cambie todo lo que se ajuste a mis costumbres. Tal vez pasen unos meses haciendo algunas cosas, viendo cómo funcionan las cosas, generando confianza y logrando algunos logros. Dado que estás preguntando aquí, parece que no estás preparado para sugerir este cambio. También tu pregunta es líder y creo argumentativa. –

+2

@apphacker: lo abogo por SourceSafe (¡que todos odian!), No por TFS (de lo que no sé nada). Solo quería saber los pros y los contras de TFS versus Mercurial para tener una mejor idea de cómo será la vida una vez que cambiemos a TFS (ya se tomó una decisión y no soy lo suficientemente mayor para cambiar eso) . –

Respuesta

33

No puede comparar directamente TFS y un DVCS.

Si su empresa se inclina hacia TFS, que puede ser debido a la other features TFS comes with (recogida de datos, elaboración de informes y seguimiento de proyectos, todo bien integrado con productos de Microsoft)


En el lado puro de control de versiones, el Team Foundation Server 2010, con Team Foundation Version Control (TFVC) 2010, introduce sucursales como ciudadano de primera clase.
Ver Team Foundation Server and branching characteristics, compared to others.

Todavía encuentro que sus modelos de ramificación son más complejos que Mercurial o Git.
Ver TFS2010 Branching into a subfolder of another branch vs Guide to Branching Model in Mercurial (y esto SO question que también detalla las fusiones y ramas con DVCS)

Dicho esto, sigue siendo un CVC (VCS centralizado), así que le darán diferentes procesos de trabajo que con un DVCS: ver Describe your workflow of using version control (VCS or DVCS) .

El true killer feature of a DVCS sigue siendo su capacidad de fusión (más simple y más rápido que cualquier CVCS). Pero introducing a DVCS in a corporate environment remains hard.

+0

Me interesa el lado del control de versiones de TFS: ¿qué hace bien/mal? –

+0

@Jackson: He completado mi respuesta en el lado de VCS de TFS. – VonC

+0

excelente - gracias por la información adicional. –

8

Recomiendo Joel en el software http://hginit.com para obtener una lista de muy buenas razones para cambiar al control de versión distribuida.

+4

Estoy de acuerdo en que Hg Init es un buen tutorial que destaca muchos beneficios con DVCS, aunque probablemente sea bueno mencionar que el autor tiene un interés económico directo en lograr que la gente cambie a Mercurial (o más precisamente, Kiln (que creo que es gran producto, pero ese no es el punto)). –

6

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

  • TFS es muy difícil de usar fuera de Visual Studio. Incluso las versiones diferentes se hacen dentro de 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 estén bajo control de versión de solo lectura. Esto hace que modificar archivos fuera de VS sea muy doloroso. De hecho, esto sigue causando problemas con los proyectos de 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. (En lo personal, me gusta usar la línea de comandos)

Antecedentes: Mi empresa cambió de SVN y TFS y utilizo Mercurial/Git para mis proyectos secundarios. También seguí este blog about using Mercurial with TFS y ha hecho que mi trabajo con TFS sea mucho más agradable.

+1

Para tocar en sus puntos. 1) .¿Cómo se puede usar TFS para escribir código? ¿te refieres a Visual Studio? 2). dll no se debe registrar, sino que se debe crear desde la fuente 3). TFS 2012 permite espacios de trabajo locales, por lo que no hay más archivos locales "fraudulentos" 4). Los utilitarios de líneas de comandos de IMO están en la misma categoría que los archivos .bat, que son meras oportunidades para que los programadores escriban los contenedores. – hanzolo

+0

1) Gracias, eso fue un error tipográfico. 2) dll es donde libs de terceros como nunit y nhibernate. 4) Actualmente uso git desde la línea de comandos y me encanta. Envolví la línea de comandos TFS en las tareas de rake y en los archivos por lotes, así que en realidad era utilizable; sin embargo, fue muy doloroso de configurar. – wusher

3

TFS es una herramienta de gestión de vida útil de aplicación no SOLO un sistema de repositorio/control de código fuente.

de de Es fuerza 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 Fuente de ella es también muy fuerte, sin embargo, en lo personal, siempre que puedo ver toda la historia, no pierde el código, y no tener mi código " pisado ". Podría dar un maldito.

He estado usando TFS desde 2008 y la última ronda de mejoras demuestra aún más los compromisos de Microsofts con la evolución de sus productos y el 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 con Mercurial profesionalmente (BitBucket/Mercurial/tortoiseHG/VisualHG), tengo que decir que las herramientas parecen un poco anticuadas. La integración con Visual Studio es como café tibio (ho-hum), y la integración del explorador me lleva a "los buenos días" cuando tuve la suerte de NO trabajar 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é mi última empresa a VSS en TFS y solo me llevó un par de utilidades de línea y de la noche a la mañana para mover todo el historial de cambios. Estaba sorprendido (como en el caso de mis colegas) de lo fácil que era la migración, incluso guardé toda la historia desde el principio (a pedido de los poderes)

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

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

de inicio con control de código fuente, terminan con especificaciones se originó en MS Project, ligada a elementos de trabajo vinculados a prueba unitaria atadas a las pruebas de aceptación atadas a automatizado construye y despliegues

Y por último: incendiar/Velocidad Gráficos

Cuestiones relacionadas