tortoise tag from create .net svn version-control tfs configuration-management

.net - tag - TFS vs SVN



tag svn (16)

Estoy a punto de comenzar un proyecto (.NET) y necesito decidir entre TFS y SVN.

Estoy más acostumbrado a SVN (con cliente de tortuga), CVS y VSS. ¿Tiene TFS todas las características disponibles en SVN?

¿Alguno de ustedes cambió de SVN a TFS y lo encontró valioso?
También parece que podemos necesitar Visual Studio si necesitamos trabajar con TFS.

[Editar]
El dinero no es una consideración ya que ya tenemos las licencias para TFS en su lugar. Y estoy más interesado en las características de control de fuente de TFS vs SVN, por supuesto, también es bienvenida la lista de otras características.

" No se puede comparar entre TFS y SVN "

SVN : es el sistema de control de código fuente
TFS : es un sistema completo de desarrollo de software que contiene, control de versiones, administración de lanzamientos, seguimiento de requisitos, publicación de documentos y otras cosas.

Ambos tienen buenos complementos de integración IDE (por ejemplo, AnkhSVN, complemento de Collabnet) disponibles para VS2005, por lo que ese no es el punto a considerar.

Criterios a considerar para la elección :
- Si tiene un proyecto de presupuesto nulo o pequeño, elija SVN
- Si solo está buscando un sistema de control de versiones, elija SVN , si está buscando una gestión de desarrollo completa, elija TFS.
- Si tiene paciencia para hacer malabares con diferentes herramientas de integración (CruiseControl.Net, NUnit, NCover, FIT) para lograr un entorno de desarrollo adecuado, elija SVN , o si está buscando la implementación lista para usar de todo esto para usted, elija TFS.

Bueno, para mí, la elección es obviamente TFS:

  • La integración de SVN en Visual Studio es incompleta, por decir lo menos (muchas características no están disponibles en el IDE), y un poco problemático (AnkhSVN ciertamente lo es), mientras que TFS one es perfecto (lo cual tiene sentido ...). He tenido todo mi espacio de trabajo corrompido varias veces usando SVN (durante un mes), nunca usando TFS (aproximadamente 2 años)

  • Si bien las características relacionadas con el control de fuente de ambos sistemas son probablemente bastante equivalentes, se puede acceder directamente desde el IDE con TFS, mientras que si usa SVN debe confiar en TortoiseSVN u otras herramientas externas. Casi todas las tareas TFS son accesibles con unos pocos clics en la pestaña del explorador de soluciones.

  • La fusión es mucho más fácil con TFS, incluso para fusiones complejas (por ejemplo, SVN agregará <<<<<< ''s y >>>>>>>>> a sus archivos .csproj , por lo que necesitará editarlos manualmente para abrirlos nuevamente desde VS.)

Aunque creo que esas razones son más que suficientes para preferir TFS a SVN, debo agregar que:

  • TFS es más que solo una herramienta de control de origen (piense en elementos de trabajo, portal de proyectos, etc.)

    Lo he usado en un proyecto de tamaño medio (12 codificadores, 3 probadores, 3 analistas de negocios) en el pasado, y hemos sido capaces de centralizar con éxito todas las tareas en TFS (informes de errores, documentación del proyecto, proceso de compilación, etc.)

    No estoy diciendo que no sea posible hacer lo mismo usando SVN y otras herramientas de terceros, pero definitivamente es bueno tener todas las cosas bien integradas en un solo producto.

Para mantenerse justo, aquí están los dos inconvenientes obvios de TFS:

  • Su precio

  • Instalar TFS es bastante molesto, mientras que la instalación de SVN es cuestión de minutos.

    Instalar TFS 2008 en SqlServer 2008 es bastante complicado, no puede instalar TFS en un PDC, etc. Para mí, definitivamente es la peor experiencia de instalación que he tenido con un producto de Microsoft.

    Dicho esto, una vez instalado, TFS es muy fácil de usar (especialmente para codificadores que no están familiarizados con los sistemas de control de fuente)

En mi proyecto actual, comencé con SVN y cambié rápidamente a TFS. Estoy feliz de haberlo hecho

La razón principal por la que he decidido cambiar es claramente el comportamiento general de errores de SVN (estaba usando VisualSVN como servidor y AnkhSVN como cliente). Al menos una vez por semana, me encontré pasando horas en mensajes de error crípticos AnkhSVN.

Hasta la fecha, no he encontrado una sola razón para lamentar el cambio a TFS.

Después de haber usado TFS 18 meses atrás, encontré un criterio de búsqueda con errores, lento, molesto y muy limitado, y tuve la sensación de que un producto se apresuró por un equipo de técnicos no interesados, mal pagados y sobreexigidos que se vieron obligados a usar Sharepoint y otros Tecnologías de MS porque eso es lo que quería el marketing. En serio, era un perro, ¡preferiría usar SourceSafe!

SVN, por otro lado, es un poco técnico, la integración IDE es un problema, y ​​de vez en cuando puede confundirse, pero la base de usuarios es masiva y la mayoría del problema se puede resolver con una rápida pregunta SO.

¿Has considerado Vault ? Funciona bien, y no es demasiado caro.

Diría que TFS es más que solo control de fuente. Si puede pagarlo, definitivamente le aconsejo que lo use. Cuando comiences a utilizar Team Builds, por ejemplo, o utilices elementos como Work Items, verás que TFS puede realmente administrar todo tu ciclo de vida de desarrollo, proporcionando un entorno rico en el que informar, facilidad de uso, integración slick VS y fuente sólida. control están todos en uno.

Requiere algo de hierro en el lado del servidor. No obstante, no creo que sea lento, funciona muy bien en VPN y admite el trabajo fuera de línea.

Un problema importante es el proceso de instalación (en el lado del servidor) que es tedioso, no flexible y en mi mente (vengo de un campo en el que las aplicaciones de empaquetado y la implementación son muy importantes) un mal ejemplo de SQL Server, Informes Servicios, Sharepoint y servicios web podrían ser instalados.

En mi experiencia SVN en general es mucho más rápido y más indoloro. Lo he usado con scripts de implementación de XCOPY que le permiten trabajar e implementar mucho más rápido en general en comparación con TFS.

Han pasado 1.5 años desde que uso SVN para varios proyectos. Configuraciones que he usado hasta ahora:

  • Cliente AnkhSVN para Visual Studio. Se integra muy bien como proveedor de control de fuente desde la versión 2.
  • Servidores CollabNet Subversion en Windows o Apache 2.2 con SSL + SVN a través de DAV en Linux.

No he tenido ningún problema con ninguna de estas configuraciones y definitivamente recomiendo usar SVN, ya que es gratis y fácil de usar. También muchos paquetes de gestión de proyectos / seguimiento de errores se integran con SVN (como trac por ejemplo).

He usado ambos, pero en realidad, cambié mis proyectos principales de TFS a SVN. Considero que el acceso fuera de línea y anónimo es muy valioso en mis proyectos.

En general, creo que son comparables. Escogería el que mejor conozca, y usted es el más feliz de mantener. No encuentro que las características específicas en una superen dramáticamente las características en el otro sistema.

No entender lo que las herramientas son capaces de hacer, sus limitaciones, significará que terminará con una herramienta que no funciona para lo que desea. Comprenda sus requisitos y lea un poco los manuales del producto; hay mucha información disponible para determinar su idoneidad.

Aunque estoy completamente de acuerdo con los proponentes de SVN, ya que es una herramienta gloriosa (la he usado muchas veces en la universidad), he encontrado que TFS generalmente es más cooperativo en situaciones OOTB cuando está utilizando la versión SP1 con Studio 2010.

Además, hay algunos pequeños complementos que hacen que TFS sea un poco más aceptable para aquellos de nosotros que estamos acostumbrados, y generalmente también prefieren una solución de tipo SVN, y muchos de ellos tienen un excelente soporte:

TeamReview for Code Reviewing es un ejemplo: http://teamreview.codeplex.com/ MS Pathways para el uso multiplataforma de TFS: http://www.microsoft.com/pathways/teamprise/FAQ.htm

Esta pregunta SO es un gran recurso para los complementos de TFS: ¿Qué complementos / utilidades están disponibles para TFS?

Una palabra para los sabios, como se mencionó anteriormente, TFS puede ser un dolor para ser instalado, por lo que se debe tener precaución. Siguiendo la ruta a continuación, he encontrado problemas mínimos:

Studio 2008 -> Patching -> Studio 2010 -> Patching -> .NET -> SQL Server 2008RD / 2012 -> Patching -> TFS -> Patching

No tengo experiencia con TFS, pero la integración con IDE es algo en lo que debes pensar. TFS obviamente se integra muy bien con Visual Studio. AnkhSVN, el único complemento gratuito utilizable para VS, a menudo es problemático, incluso en las nuevas versiones. Aunque no he probado VisualSVN.

Si estás familiarizado con svn, me quedaría con él. Tfs no es gratis y no es simple. Hace mucho más que el control de fuente. Si usted es una tienda de .net como nosotros y está decidiendo qué producto utilizar para todo el ciclo de desarrollo, es un competidor, pero para el control de fuente simple es excesivo.

Solo recomendaría TFS si estuviera usando la versión 2013 y use el repositorio basado en Git. He encontrado demasiados problemas con las versiones anteriores para considerarlos estables.

  • Es imposible enviar múltiples archivos a su herramienta diff a la vez. Esto es ridículamente útil cuando quiere revisar sus cambios antes de una fusión y no está disponible.
  • Disponibilidad incoherente de funcionalidad. Algunas funcionalidades solo están disponibles desde el IDE, mientras que otras solo están disponibles desde Windows Explorer, mientras que otras solo están disponibles desde la línea de comandos.
  • Agregar archivos al control de versiones no está disponible desde el IDE y solo está disponible desde la integración del Explorador de Windows.
  • El acceso a conjuntos de estantería solo está disponible desde el IDE y no está disponible a través de la integración de Windows Explorer.
  • La falta de un solo instalador unificado. No basta con instalar TFS, también tiene que instalar herramientas de equipo y herramientas eléctricas para obtener una funcionalidad básica.
  • La funcionalidad del conjunto de estantería no se fusiona. Lo que podría haber sido una forma genial de hacer sucursales privadas, esencialmente garantiza que su código se desactualice y deje de funcionar.
  • Debe desbloquear manualmente los archivos de texto antes de editarlos si necesita usar un editor que no sea Visual Studio.
  • En ocasiones, Visual Studio se olvida de desbloquear los archivos que él mismo está administrando y arroja un error.
  • Las IU de entrada y de archivado basan los archivos disponibles para confirmar lo que ya se ha agregado a TFS y no lo que realmente está presente en el sistema de archivos. Esto hace que sea extremadamente fácil perder archivos. (Esto es en realidad un problema con la forma en que Visual Studio maneja los archivos de proyecto, pero eso en sí mismo es otra diatriba).
  • Es innecesariamente difícil utilizar herramientas que no sean de Microsoft para editar su fuente debido a los problemas mencionados anteriormente.
  • La configuración de TFS está comprometida con su fuente. Esto significa que si cambia su servidor TFS, la configuración de todo su historial ahora es incorrecta. Hay una configuración predeterminada que puede usar que anula este comportamiento pero no es obvio.
  • No hay soporte para ignorar filtros en cualquier cosa que no sea el nivel base.
  • Incapacidad para manejar rutas de más de 249 caracteres.
  • Los archivos que se han desbloqueado, pero no editado, se muestran como cambiados, aunque no lo hayan sido. Diferenciar entre cambiar y desbloquear haría mucho más fácil para diffs, o mejor aún, eliminar todo el sistema de desbloqueo completo.
  • Las superposiciones de iconos de Windows Explorer no muestran claramente si un archivo ha sido editado. Todos los archivos en TFS tienen una esquina verde, mientras que los archivos modificados agregan un lápiz en la parte inferior del ícono. Cambiar a la esquina roja para modificar sería mucho más fácil de ver o usar el sistema de iconos de tortuga.
  • Las versiones anteriores de Visual Studio tienen problemas para integrarse en las versiones más nuevas de TFS. Esto significa que ahora tenemos una dependencia de la versión IDE en el control de fuente.
  • Incluye los archivos de la solución del usuario por defecto cuando no son necesarios. Por supuesto, admitiré que esta podría ser una cuestión de preferencia.
  • El mal almacenamiento en caché hace posible que las diferencias entre su copia local y el servidor no se reflejen con precisión. Es extremadamente frustrante obtener lo último y descubrir que en realidad no tienes lo último.

TFS puede importar desde SVN, sin embargo, SVN no puede importar desde TFS. Entonces, si no encuentra una buena razón, use SVN, ya que es más fácil cambiar de opinión más adelante.

Una de las mejores cosas de SVN es que todos los sistemas de control de código fuente que conozco pueden importar a partir de él, por lo que elegir SVN es una opción de muy bajo riesgo.

Tenga en cuenta que TFS 2010 se puede instalar también en sistemas operativos cliente Windows Vista / 7 y que es compatible con una instalación expresa de tres clics.

Yo escogería SVN. He trabajado con SVN desde el punto de vista de desarrollador y actualmente trabajo con TFS, y déjame decirte que TFS es doloroso. Si bien TFS tiene funciones completas y es más que solo control de versiones, su control de versiones es, en el mejor de los casos, descuidado. La fusión es terrible y muchos de nosotros ahora recurrimos a herramientas de combinación o fusión manual porque no podemos confiar en TFS. Los archivos faltan, no se descargan en el sistema local a veces, y hay comportamientos curiosos que hacen que quieras golpearte la cabeza contra un escritorio.

Dicho eso, si quieres TFS en todo su esplendor, estás dispuesto a trabajar con sus puntos débiles, es una gran herramienta para configurar versiones automáticas y lanzamientos.

Pros:

  • Integración con Visual Studio . Una ventaja real si aprovecha una tecnología completa de Microsoft. pila para el desarrollo.
  • Las compilaciones automatizadas (aunque se pueden lograr a través de otros productos) están muy bien hechas. La integración continua y las compilaciones de check-in seguras son fantásticas IMO.

Contras:

  • Windows Workflow Foundation . Por alguna razón, se eligió Windows Workflow Foundation como el método para personalizar muchos aspectos de TFS. En resumen, necesita un libro sobre Windows Workflow para comprenderlo, y simplemente no tengo tiempo. Muy decepcionante IMO.
  • Gestión de proyectos . El concepto de elementos de trabajo es bastante simple, supongo, pero hay muchas rarezas que me dejan atónito. Es demasiado complicado IMO. Viniendo de un fondo de Trac + SVN, prefiero Trac aquí. De nuevo, solo mi opinión.