TFS vs SVN [cerrado]

"No se puede comparar entre TFS y SVN"

SVN: es un Sistema de Control de Versiones de Código Fuente
TFS : es un sistema de Gestión de Desarrollo de Software completo que contiene, Control de versiones, Administración de versiones, seguimiento de requisitos, Publicación de documentos y otras cosas.

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

Criterios para considere la opción :
- Si tiene un proyecto sin presupuesto o con un presupuesto pequeño, elija SVN
- Si solo está buscando un sistema de control de versiones, elija SVN , si está buscando una gestión completa del desarrollo, elija TFS
- Si tienes 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 una implementación fuera de la caja de todos estos para que luego elija TFS

Después de haber utilizado TFS 18 meses atrás me pareció buggy, lento, molesto, criterios de búsqueda muy limitados y tenía la sensación de un producto precipitado por un equipo de técnicos no interesados, mal pagados, más trabajados que se ven obligados a utilizar Sharepoint y otras tecnologías de MS porque eso es lo que el marketing quería. En serio, era un perro, hubiera preferido utilizar SourceSafe!

SVN por otro lado es bit techie, la integración IDE es un dolor, y ocasionalmente puede confundirse, pero la base de usuarios es masivo y la mayoría de los problemas se pueden resolver con una quesition TAN rápida.

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

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

• Es imposible enviar varios archivos a su herramienta de diferencias a la vez. Esto es ridículamente útil cuando desea revisar sus cambios antes de una fusión y no está disponible.
• Disponibilidad inconsistente de la funcionalidad. Algunas funcionalidades están disponibles solo dentro del IDE mientras que otras las piezas solo están disponibles desde el Explorador de Windows, 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 los conjuntos de estanterías solo está disponible desde el IDE y no a través de la integración del explorador de Windows.
• Falta de un único instalador unificado. No basta con instalar TFS, también hay que instalar herramientas de equipo y herramientas eléctricas para obtenga la funcionalidad básica.
• La funcionalidad del conjunto de estanterías no se fusiona. Lo que podría haber sido una forma genial de hacer ramas privadas, esencialmente garantiza que su código se desactualizará y dejará de funcionar.
• Debe desbloquear manualmente los archivos de texto antes de editarlos si necesita usar un editor que no sea Visual Studio.
• A veces Visual Studio se olvida de desbloquear archivos que él mismo está administrando y lanza un error.
• El registro y la estantería de archivos UIs base disponibles para confirmar lo que ya se ha agregado a TFS y no lo que realmente está presente dentro del 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 usar herramientas que no sean de Microsoft para editar su fuente debido a los problemas mencionados anteriormente.
• La configuración de TFS se confirma con su fuente. Esto significa que si cambia su TFS servidor 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 obvia.
• No hay soporte para filtros ignorados en nada excepto en el nivel base.
• Incapacidad para manejar rutas de más de 249 caracteres.
• Los archivos que han sido desbloqueados, pero no editados se muestran como modificados, aunque no lo hayan sido. Diferenciar entre cambiado y desbloqueado haría que sea mucho más fácil para las diferencias, o mejor aún, acabar con todo el sistema de desbloqueo roto por completo.
• Las superposiciones de iconos del explorador de Windows no muestran claramente si se ha editado un archivo. Todos los archivos en TFS tienen una esquina verde, mientras que los archivos modificados agregan un lápiz a la parte inferior del icono. Cambiar a red corner para modified sería mucho más fácil de ver o usar el sistema de iconos tortoise.
• Las versiones anteriores de Visual Studio tienen problemas para integrarse en las versiones más recientes de TFS. Esto significa que ahora tenemos un IDE dependencia de la versión en el control de código fuente.
• Incluye los archivos de la solución de usuario por defecto cuando no son necesarios. Por supuesto que admitiré que esta podría ser una cuestión de preferencia.
• El almacenamiento en caché incorrecto hace posible que las diferencias entre su copia local y el servidor no se reflejen con precisión. Es extremadamente frustrante obtener la última y descubrir que en realidad no tiene la última.

Hace 1,5 años que uso SVN para varios proyectos. Configuraciones que he usado hasta ahora:

• AnkhSVN cliente para Visual Studio. Se integra muy bien como proveedor de control de código 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 comenzar a usar. También muchos los paquetes de gestión de proyectos / seguimiento de errores se integran con SVN (como trac por ejemplo).

Yo elegiría SVN. He trabajado con SVN desde el punto de vista del desarrollador antes y actualmente trabajo con TFS, y déjame decirte que TFS es doloroso. Mientras que TFS está lleno de funciones y es más que solo control de versiones, su control de versiones es descuidado en el mejor de los casos. La fusión es horrenda y muchos de nosotros ahora recurrimos a la fusión manual o a las herramientas de fusión porque no podemos confiar en TFS. Los archivos desaparecen, no se descargan en el sistema local a veces, y solo hay rarezas en su comportamiento que hacen que desee golpea tu cabeza contra un escritorio.

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

He usado ambos, pero en realidad, he cambiado mis proyectos principales de TFS a SVN. Encuentro el acceso offline y anónimo muy valioso en mis proyectos.

En general, creo que son comparables. Solo elegiría el que mejor conoces, y eres el más feliz de mantener. No encuentro que las características específicas en uno superen dramáticamente las características en el otro sistema.

Echa un vistazo a este artículo antes de decidir: Una comparación de TFS vs Subversion para Proyectos de Código Abierto

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

Yo diría que TFS es más que solo control de código fuente. Si puede permitírselo, definitivamente le recomendaría usarlo. Cuando comiences a usar Compilaciones de equipo, por ejemplo, o a usar cosas como Elementos de trabajo, entonces verás que TFS realmente puede administrar todo tu ciclo de vida de desarrollo, proporcionando un entorno rico en el que la generación de informes, la facilidad de uso, la integración VS.

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

Una gran estafa 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 el empaquetado de aplicaciones y la implementación son muy importantes) un mal ejemplo de cómo SQL Server, Reporting Services, Sharepoint y webservices podrían instalarse.

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

Una de las mejores cosas de SVN es que cada sistema de control de código fuente que conozco puede importarlo, por lo que elegir SVN us es una opción de muy bajo riesgo.

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

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

Tenga en cuenta que TFS 2010 también se puede instalar en Windows Vista / 7 client OSs y que admite una instalación rápida de tres clics.

Ventajas:

• Integración con Visual Studio. Una verdadera ventaja si está aprovechando una tecnología completa de Microsoft. pila para el desarrollo.
• Compilaciones automatizadas (aunque alcanzables a través de otros productos) está muy bien hecho. La integración continua y las construcciones de check-in cerradas son fantásticas para IMO.

Contras:

• Windows Workflow Foundation . Por alguna razón, Windows Workflow Foundation fue elegido como el método para personaliza muchos aspectos de TFS. En resumen, necesita un libro sobre el flujo de trabajo de Windows para entenderlo, y simplemente no tengo el tiempo. Muy decepcionante IMO.
• Gestión de proyectos. El concepto de artículos de trabajo es bastante simple, supongo, pero hay muchas rarezas con él que me dejan desconcertado. Es demasiado complicado IMO. Viniendo de un fondo Trac + SVN, prefiero mucho Trac aquí. De nuevo, solo mi opinión.

No entender de qué son capaces las herramientas, sus limitaciones, significará que terminas con una herramienta que no funciona para lo que quieres. Comprenda sus requisitos y lea un poco los manuales de los productos: mucha información disponible para determinar la idoneidad.

Si bien estoy completamente de acuerdo con los defensores 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 de OOTB cuando está utilizando el Versión SP1 con Studio 2010.

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

TeamReview para la revisión de código es un ejemplo: http://teamreview.codeplex.com / Vías de los Estados miembros para el uso multiplataforma de las FT: http://www.microsoft.com/pathways/teamprise/FAQ.htm

Esta Es la Pregunta es un gran recurso para complementos de TFS: ¿Qué Complementos / utilidades están disponibles para TFS?

Una palabra para el sabio, como se mencionó anteriormente, TFS puede ser un dolor para ser instalado, por lo que se debe tener cuidado. 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