SVN vs Team Foundation Server [cerrado]

Aquí están las mayores diferencias entre los dos para mí, y he utilizado ambos:

1) TFS está estrechamente acoplado a la "forma Visual Studio" de hacer el desarrollo. Eso no quiere decir que TFS esté estrechamente acoplado al IDE VS, significa que TFS lucha por mantener el paradigma familiar de "check in"/"check out" de Visual SourceSafe, incluso cuando realmente ya no es un modelo apropiado. El concepto de Subversion de "commit" / "update" es mucho más realista cuando se tiene desarrolladores que podrían pasar tiempo desconectados de la red. TFS espera que los desarrolladores siempre estén conectados al servidor. Eso es un gran inconveniente. Personalmente, considero que TFS no es muy transparente sobre cómo se organizan los archivos en el servidor y en su disco local debido a la estrecha integración de Visual Studio. Incluso los defensores más grandes de TFS admiten que su modelo de check-in/check-out conectado no es una opción convincente para los desarrolladores que trabajan desconectados. En un clima donde la gente está comenzando a mirar las opciones de DVCS como git y Mercurial sobre SVN, el modelo "check out" de TFS parece un poco como un dinosaurio.

2) Costo. Aquellos que dicen que TFS no es caro son probablemente tiendas muy pequeñas o no cumplen con los términos de licencia de TFS. Necesita una licencia de acceso de cliente para darn cerca de todo lo que hace. ¿Eres un gerente que solo maneja los errores? Necesita una CAL de ~ ~ 250 (hay 5 incluidos con una licencia TFS minorista). Un usuario de negocios que solo quiere para informar sobre sus problemas? Un CAL de 2 250. Un desarrollador? $250 (A menos que tengan MSDN en cuyo caso está incluido). El servidor? $500 (Incluido si tiene MSDN). Por supuesto, alguien que le venda una copia de TFS le dirá que el seguimiento de elementos de trabajo es gratuito para usuarios adicionales, pero estos usuarios adicionales solo pueden ver los elementos de trabajo que ellos mismos crean, y no los elementos de trabajo de todo el equipo, lo que no es demasiado útil en un entorno ágil y orientado al equipo. Todo esto se suma cuando se tiene un organización de tamaño medio, y se vuelve difícil de justificar cuando tantos productos mejores de su clase como SVN y CruiseControl.net ' s costo incremental es de 0 0. (Para ser justos con TFS, sin embargo, todavía estoy esperando un realmente buen rastreador de problemas de OSS)

3) estructura del Proyecto. En equipos grandes con un número menor de proyectos, los TFS probablemente funcionarán bien. Si tiene varias aplicaciones de línea de negocio pequeñas, desconectadas o poco conectadas internamente, la estructura de TFS puede comenzar a convertirse en dominante. Por un lado, no es posible definir una taxonomía de los propios proyectos you puede configurar "Áreas" dentro de un proyecto, pero todos los problemas y documentos se rastrean juntos dentro del contexto básico de un "proyecto". La creación de nuevos "proyectos" a menudo consume mucho tiempo y es excesiva para pequeños esfuerzos. Por supuesto, SVN no tiene nada de eso, ya que se centra solo en el control del código fuente, pero si necesita una buena flexibilidad para proyectos pequeños, SVN y otra herramienta de seguimiento de problemas podrían ser mejores opción.

Mi opinión, por si sirve de algo:

• Para equipos grandes con proyectos grandes y bien presupuestados, en una tienda de Microsoft donde los desarrolladores trabajan casi exclusivamente dentro del IDE, TFS es el ganador. TFS también gana cuando necesita hacer cumplir la política de forma centralizada con sus proyectos.

• Para un número de equipos pequeños, con muchos proyectos variados y más pequeños, o tiendas donde el costo es un problema, o equipos que tienen desarrolladores que trabajan desconectados del control de código fuente, vaya con SVN.

Me sorprende que alguien que haya usado Subversion en el pasado incluso tenga un deseo/necesidad de control de código fuente TFS.

Mi experiencia con TFS (2005) ha sido bastante horrible. He leído todo tipo de documentos técnicos y orientación sobre cómo estructurar adecuadamente su fuente para diversas necesidades de desarrollo.

Nuestra situación simple, donde tenemos un tronco con desarrollo de línea principal, y una rama de integración donde integramos cambios y desplegamos, y una rama de lanzamientos para realizar un seguimiento de los lanzamientos anteriores son muy comunes y sencillos, pero continuamente nos encontramos con problemas.

Mis principales problemas con TFS:

• Fusionar es un dolor en comparación con subversion.
• Hay errores no arreglados. Me encontré con uno sobre el cambio de nombre / fusión que se ha conocido durante 2 años y una solución nunca será lanzado para 2005. Terminamos moviendo nuestra rama a una carpeta" rota " y la ignoramos ahora.
• Poner bloqueos de solo lectura en sus archivos es fricción. ¿Quién dice que ¿necesita editar archivos por lotes y construir scripts dentro de TFS para que "lo compruebe" por mí? Subversion sabe qué archivos han cambiado. No hay cerraduras de solo lectura allí.
• Velocidad. TFS es lento para perros sobre una WAN, y realmente solo se puede usar si VPN en mi computadora de trabajo, lo que hace que mi experiencia de desarrollo sea realmente lenta en general.
• Falta de una buena integración de línea de comandos y explorador. La integración con IDE es realmente agradable para el día a día, agregar archivos y registrarse, pero cuando necesitas hacer cosas en muchos proyectos, es bueno tener buenas herramientas a tu disposición. Y antes de que alguien salte por mi garganta reclamando tf.exe funciona bien... no es realmente una herramienta de línea cmd. Por ejemplo, la comprobación de código no debería abrir un cuadro de diálogo modal.

...la lista continúa. Creo que incluso con toda la integración, hay alternativas gratuitas que son muy superiores.

Somos un VS.NET tienda, e implementamos:

1. Bugzilla para el seguimiento de problemas
2. Apache Subversion como un repositorio de código fuente back-end
3. VisualSVN Server para administrar SVN en el servidor
4. TortoiseSVN (en el Explorador de Windows) y AhnkSVN o VisualSVN (en Visual Studio) en el cliente
5. CruiseControl.NET para compilaciones automatizadas

Costo: $0 Beneficio: Inestimable

Si usted es un equipo pequeño, o no está listo para comprar en el proceso de TFS de la oms, SVN y las herramientas de código abierto son el camino a seguir.

Como otros han señalado, TFS le da muchas más características que SVN en forma de gestión de proyectos y cosas por el estilo. Después de haber utilizado ambos, y trabajado con empresas muy grandes en la implementación de TFS, aquí están mis dos centavos.

1) Si está utilizando TFS 2005, actualice a TFS 2008. Me lo agradecerás. Hay un montón de mejoras en TFS 2008 que lo hacen viable.

2) Si vive en Visual Studio y desea la integración IDE, vaya con TFS. He utilizado la integración SVN y casi siempre vuelva a usar TortoiseSVN.

3) Si te gusta la idea de integrar cuentas con Autenticación de Windows, ve con TFS. La manejabilidad desde ese extremo es agradable. Puede haber hooks para SVN-no estoy seguro, pero si te gusta la gestión GUI, TFS es difícil de superar.

4) Si necesita realizar un seguimiento de las métricas o tener formas más fáciles de implementar cosas como políticas de registro, vaya con TFS.

5) Si tiene personas que no lo implementarán si no es MSFT, vaya con TFS.

6) Si hace algo más que.NET (Java work, Eclipse, etc.) vaya con SVN. Sí, hay productos muy buenos (como Teamprise) que funcionan bien con TFS. Pero a menos que los otros idiomas sean una pequeña parte de su tienda, simplemente siga con SVN.

Fuera de eso, las características de SCM de ambos son casi equivalentes. Ambos hacen ramificación y fusión, ambos hacen check-ins atómicos, ambos admiten cambios de nombre y movimientos. Creo que para la gente que acaba de empezar con la ramificación y el concepto de fusión, tener las ramas visibles en el Explorador de control de código fuente es agradable.

TFS realmente no es tan caro (maybe 1200 tal vez?). Comparado con SVN es, tal vez. La integración con reporting services y SharePoint es agradable, pero de nuevo, si no está usando eso, entonces no importa.

Lo que yo diría es descargar la versión de prueba de 180 días de TFS y darle una oportunidad. Haz un juicio lado a lado. Creo que serás feliz no importa por dónde vayas.

Como Ubiguchi señala, TFS no es un producto de control de versiones. Comprar TFS con la intención de usarlo solo para el Control de Versiones sería claramente una pérdida de dinero. TFS es un conjunto integrado de herramientas para automatizar todos los aspectos de la Gestión del ciclo de vida de las aplicaciones (y más o menos orientado a "La Empresa").

También según el post de Ben S - No entiendo tu comentario sobre las cerraduras. Los bloqueos no son necesarios en TFS. Los administradores pueden configurar TFS para que funcione como VSS (características exigido por algunos clientes "imprudentes") para "Obtener lo último en la caja", que creo que también hace un bloqueo de salida.

Pero a través del uso "normal" de TFS, un "check-out" solicita al usuario el tipo de bloqueo, y el valor predeterminado debe ser "none". Un usuario PUEDE seleccionar un check-out (o un bloqueo de check-in), pero no es necesario. Si no quieres cerraduras, no las uses.

TFS hace un seguimiento de los usuarios que tienen salidas en el servidor por varias razones de rendimiento (hacer que get-latest sea más rápido) y proyecto administración (me gusta ver qué desarrolladores tienen archivos descargados y cuánto tiempo duran sus registros).

No estoy realmente familiarizado con SVN (nunca lo he usado) - así que no puedo comentar que "la fusión es peor con TFS" - y no he golpeado el error de fusión que Ben S informó - pero he tenido un gran éxito con la ramificación y la fusión con TFS.

Un caso de uso que sé que TFS todavía es bastante débil es para los usuarios que están regularmente "fuera de línea". TFS es un "Producto Servidor" que asume que los usuarios están conectados la mayoría del tiempo. La experiencia fuera de línea mejoró en el lanzamiento de 2008 (fue triste en 2005), pero todavía tiene un largo camino por recorrer. Si tiene desarrolladores que necesitan (o quieren) estar desconectados de la red durante largos períodos de tiempo, es probable que esté mejor con SVN.

Otra característica a considerar para los fans de SVN que están usando TFS es el SVN Bridge un codeplex que permite a los usuarios usar TortiseSVN para conectarse a TFS. Yo buen amigo y colega mío lo usa ampliamente y le encanta.

También me sorprende el comentario sobre la falta de línea de comandos: las herramientas de línea de comandos son extensas (aunque muchas requieren una descarga separada de TFS Power Tools

Sospecho que los comentarios de Ben se basan en una evaluación de la versión de 2005 que era claramente un producto "Microsoft V1.0". El producto está actualmente en 2.1 con la versión 3 en un futuro próximo.

TFS es atroz. En este punto control de versiones localmente usando SVN (w / Live Mesh para copias de seguridad) porque tengo algunos muchos problemas con TFS. El principal problema es que TFS utiliza marcas de tiempo para registrar si tiene la última versión, y almacena estas marcas de tiempo en el servidor. Puede eliminar su copia local, obtener la última versión de TFS y dirá que todos los archivos están actualizados. Es un sistema tonto que no le da ninguna garantía de que tiene la versión correcta de los archivos. Esto resulta en numerosos molestias:

• TFS necesita ser informado cuando se edita cualquier archivo, por lo que debe estar conectado al servidor en todo momento.
• Los TFS se confunden si edita archivos fuera del IDE. Además establece todos los archivos a readonly en NTFS.

Mientras que TFS soporta la fusión, es realmente un sistema de checkin/checkout. Si edita un archivo, a menudo encontrará que está bloqueado para otros desarrolladores. Hay formas de evitarlo, pero el sistema es tan enrevesado que siempre te encontrarás cuestión. Por ejemplo, nuestros desarrolladores descubrieron que pueden sortear todos los archivos configurados como readonly en NTFS al revisar una solución completa, que establece un bloqueo exclusivo en todos los archivos. Hice esto varias veces porque subversion tiene la misma sintaxis para checkout, que no adquiere un bloqueo.

Finalmente Team Explorer (el cliente) es la friolera de 400 MB, el servidor TFS requiere SharePoint y dos días para instalarlo. El instalador de subversion one click es de aproximadamente 30 MB y se instalará el servidor para usted en menos de un minuto. TFS tiene muchas características, pero su base es tan inestable que nunca las usará ni se preocupará por ellas. TFS es caro en términos de licencia, y en el tiempo los desarrolladores desperdiciarán despotricar en stackoverflow en lugar de escribir código: P

Mi recomendación, Sistema de equipo no vale la pena el dinero. He usado ambos y después de usar Team System, traté de encontrar un reemplazo similar. Básicamente lo que está pagando es la integración y se podría argumentar el soporte de personalización, pero he sido capaz de crear un Equipo de reemplazo del Sistema con un poco de tiempo y herramientas de integración juntos.

Recientemente hice una pregunta sobre lo que otros han hecho para llegar a una alternativa de Sistema de Equipo. También enumero la herramientas de desarrollo que utilicé para crear el reemplazo. Esperemos que con esta respuesta y la pregunta que hice, usted puede encontrar lo que funciona para usted.

No soy un odiador del Sistema de Equipos, simplemente no creo que valga la pena el dinero. Es una herramienta muy bonita y si no te importa pagar el precio por ella, entonces por todos los medios úsala. Fue la razón por la que creé el reemplazo que se me ocurrió. Quería el Sistema de Equipo de funcionalidad proporcionado.

Aquí hay una versión de código abierto de VisualSVN llamada Ankhsvn. Es mucho mejor ahora que collabnet se ha hecho cargo.

Si todo lo que necesita es control de código fuente, TFS es excesivo. Uno de mis empleadores anteriores tenía TFS, VSS y Subversion en su empresa. No teníamos Active Directory o Exchange Server 2003 en nuestra empresa, por lo que terminamos creando usuarios separados en el servidor TFS para que los desarrolladores pudieran usarlo. Tuvimos el mismo tipo de problemas con la fusión que mencionó Ben Schierman, junto con otro comportamiento con errores que nos empujó hacia la Subversión.

Si TFS es la llamada correcta para usted depende en parte de su presupuesto, el tamaño de su equipo de desarrollo y la cantidad de tiempo y personal disponible para la configuración/mantenimiento de su solución. Si desea las capacidades adicionales de seguimiento de problemas, elementos de trabajo y estadísticas de proyectos que proporciona TFS, puede que valga la pena buscar otras alternativas. Productos como JIRA (de Atlassian Systems) o Trac se integran bien con Subversion y proporcionan el tipo de supervisión que un gerente de proyecto o programa podría tener a un nivel inferior precio.

En un entorno ideal, con Active Directory, Exchange Server 2003 o superior, y personal dedicado para el repositorio, es más probable que TFS sea una buena opción.

He usado tanto en el trabajo como en casa. Ambos son muy geniales por derecho propio. Sin embargo, la única vez que recomendaría usar TFS es si usará más características que solo el control de código fuente. Si todo lo que necesita es control de código fuente, no puede equivocarse con SVN y esta es la razón.

1. VisualSVN Server Que es un servidor SVN completo con un buen plugin para gestionarlo. Le permite usar la autenticación de Windows directamente a través de la interfaz de usuario. Sencillo.

2. Tortuga Su tortuga, ya está dicho.

3. Ankhsvn Es un gran plugin SCC. Para aquellos que quieren integración completa VS IDE la última versión es un plugin SCC completo. Así que ahora obtiene la integración completa de forma gratuita.

La configuración anterior es 100% gratuita y te llevará a través de cualquier cosa que necesites para el control de código fuente.

TFS no se trata solo de Control de código fuente. Si utiliza todo el paquete que ofrece TFS, seguimiento de errores, compilaciones, informes, etc, entonces TFS es una opción bastante sólida (ciertamente mejor que Rational). TFS también se integra bien con Active Directory.

Aunque si solo estás hablando de SCM, entonces prefiero SubVersion. Realmente no me gusta la integración IDE. También me gusta la convención de SVN de estructura Trunk / Tags / Branches, y la relativa facilidad de cambiar entre ramas. La fusión parecía más fácil en TFS aunque. Sin embargo, la interfaz de usuario de Tortoise supera a la de TFS, especialmente en lo que respecta a agregar un archivo a un repositorio.

Yo diría que realmente depende de sus necesidades. TFS es muy agradable, lo he utilizado ampliamente, pero está muy dirigido al nivel empresarial, si no necesita todas esas características, puede que no sea necesario. Si necesita esas características (especialmente ramificación, escalabilidad, seguimiento de elementos de trabajo, etc. valen cada centavo. Tenga en cuenta que TFS incluye seguimiento de errores, seguimiento de elementos de trabajo y otras características más allá del control de origen. Si tienes varias sucursales o si te encuentras luchando contra alguna falta de características u otras en Subversion, entonces podría ser una buena idea cambiar. Pero salvo una buena razón para cambiar, probablemente debería evitar el impacto del costo y la productividad de cambiar los sistemas de control de fuente.

Después de haber utilizado ambos ampliamente, creo que Wedge estaba en el dinero en señalar "TFS incluye el seguimiento de errores, seguimiento de elementos de trabajo y otras características más allá del control de código fuente".

Sin embargo, honestamente puedo decir que SVN y TFS parecen bastante iguales en lo que respecta a la escalabilidad, y en todo caso el control de código fuente de SVN tiene la ventaja sobre TFS debido a su simplicidad inherente.

Si desea el seguimiento de elementos de trabajo y errores junto con su control de código fuente, entonces vaya por TFS o vaya con SVN y algunos otras herramientas, posiblemente gratuitas, como bugzilla. Si bien TFS integra tanto el control de código fuente como el seguimiento de elementos de trabajo, honestamente creo que MS debería haberlo regalado gratis como una disculpa por abusar de tantos desarrolladores con VSS a lo largo de los años.

He utilizado tanto SVN como TFS. La principal ventaja de usar TFS es su estrecha integración con Visual Studio. Seguimiento de Errores, Seguimiento de Tareas todo irá en un solo lugar. Y los informes generados para estos elementos ayudarán a los interesados a mantenerse informados del estado del proyecto.

Estoy trabajando en un proyecto con 5 personas y recientemente cambiamos de SVN a TFS. Todo el proceso ha sido una pesadilla. Tenemos código generado automáticamente desde XMLSpy y TFS no reconoce los archivos modificados fuera de VS2008. Las herramientas eléctricas TFS pueden escanear su pago y solucionar este problema, pero es un dolor tener que recordar usar estas herramientas. Otro problema con el que nos encontramos constantemente es la herramienta de fusión predeterminada en TFS. Es, con mucho, la peor herramienta de fusión que he usado. Uno pensaría que TFS sería capaz de manejar fusiones de soluciones básicas, pero hasta ahora no ha sido el caso.

La interfaz de usuario incorporada es muy útil, pero también tiene defectos. Si me checkout desde mi explorador de soluciones, a veces los archivos que se han agregado no están desprotegidos. Si lo hago desde la ventana de Control de Código fuente del Equipo funciona perfectamente. ¿Por qué es eso? Espero TFS en VS2010, ya que he escuchado grandes cosas al respecto, y SVN está lejos de ser perfecto, pero habría esperado algunos de estos características para funcionar un poco más intuitivamente.

Adam

TFS es excelente para la gestión y el seguimiento de proyectos, sin embargo, siento que el control de código fuente no es tan bueno como SVN. Aquí están mis problemas con TFS:

Modelo de entrada/salida

Esta es una gran estafa para el control de código fuente de TFS. Desafortunadamente, VS comprueba automáticamente los elementos por ti, incluso si no quieres. He estado en una situación en la que alguien revisó algunos archivos y luego se fue de vacaciones. Yo estaba a cargo de la reestructuración de la estructura de directorios, pero no pudo porque un montón de archivos fueron comprobados a esa persona. No hay forma en la GUI de deshacer el proceso de pago, lo que significaba que tenía que hacerse uno por uno en la línea de comandos. O tuve que averiguar cómo escribir un script de shell de energía para esto.

VS se requiere para hacer todo

A veces quiero editar un archivo de texto y registrarlo. Esto requiere que arranque VS 2010, que es una bestia enorme, solo para editar un archivo y registrarlo. Algo que tomó unos segundos con SVN ahora me lleva un minuto.

Como algunos otros señalaron, los archivos se marcan como de solo lectura si no se extraen. Si lo hace escribible y lo edita fuera de VS, TFS no lo reconocerá. Esto hace que la edición sea algo fuera de VS molesto. Esto significa, encender VS, revisar el archivo, editarlo otro editor, verificar en VS.

Algunas operaciones que eran fáciles en SVN ahora son un dolor

• Tal vez no lo he descubierto todavía, pero encontré que rodando volver un conjunto de cambios era muy tedioso con TFS.

• Agregar archivos al control de código fuente, que no son parte de una solución, es un gran dolor. El explorador de control de código fuente de TFS solo muestra qué archivos están en control de código fuente, no cuáles no (tal vez haya una configuración en algún lugar para esto, no lo sé). Con Tortoise SVN, simplemente podría presionar Commit en una carpeta y seleccionar qué archivos agregar.

Actualmente estoy liderando el esfuerzo para evaluar TFS en mi empresa contra la Suite Rational que es lo que usamos actualmente. Hasta ahora TFS 2008 está pwning clearcase + clearquest. La integración del entorno de desarrollo es donde realmente brilla.

Mis 10 centavos:

TFS2005 fue una broma-difícil de instalar y aún más difícil de mantener TFS2008 fue estable-más fácil de instalar, mantenimiento más sencillo y compilaciones automatizadas que funcionan. TFS2010 es ÉPICO! - la instalación es perro eassssyyy. La administración es muy fácil; todo es una interfaz de usuario bien diseñada. Integrarlo con VS2008 no es tan fácil ya que no puedes crear proyectos en vs2008 tienes que usar vs2010 (lo cual es estúpido). TFS2010 también le permite cambiar la ubicación del proyecto de Sharepoint en lugar de tener esas horribles subcarpetas de TFS2008. TFS2010 también tiene herramientas como un gráfico de quemado que es realmente útil para la gestión de proyectos. Es como TFS2010 es para todo el equipo de producción, incluidos los clientes! Sin embargo, todavía cuesta demasiado: (

También tenga en cuenta que TFS requiere muchos más caballos de fuerza del hardware del servidor. Y como mínimo una licencia de Windows Server, por supuesto.

La mejor práctica, como nuestra empresa siguió, es usar 2 servidores: front-end (con sharepoint integrado) y un servidor sql dedicado en el back-end (usamos un clúster empresarial). TFS se puede instalar en 1 máquina, pero no debe.

En comparación, nuestro servidor svn está instalado en un servidor linux virtual con 256 mb de ram y 1 cpu, y sigue siendo varias magnitudes más rápido al hacer tareas comunes como checkout-all. ¡El hardware virtual era el más bajo que vshpere podía asignar! El disco es rápido (SAN).

Sugeriría que TFS requiere hardware dedicado por lo menos 5 5000, mientras que el servidor svn (en linux) puede ejecutarse con cualquier hardware que esté obsoleto para el sistema operativo actual basado en Windows.

En mi opinión, depende de la situación y el entorno en el que se realice el proyecto. Si solo tienes un proyecto simple y pequeño, entonces SVN es genial. Como ya algunos escribieron, VisualSVN se integra muy bien en Visual Studio s. t. no tiene que hacer el checkin/checkout sobre el sistema de archivos nativo.

TFS es genial para el control de versiones, pero aún mejor si realmente usas todas sus capacidades. En mis ojos, realmente vale la pena si utiliza, por ejemplo, los elementos de trabajo como su repositorio integrado para el manejo de informes de errores de clientes, solicitudes de nuevas características y para el seguimiento del progreso de su proyecto mediante la gestión de tareas y el tiempo estimado de acuerdo, el tiempo utilizado y las indicaciones de tiempo restante.
Lo que también es realmente interesante es utilizar la función de asociar elementos de trabajo con checkins de código fuente. Vea aquí para más información sobre eso.

Somos un pequeño equipo en el proceso de migración de SVN a TFS2010. Nuestra mayor razón para hacerlo es la integración en Visual Studio y el WebAccess para bugtracking, que ahora es parte del TFS.

@ Adam: Esperemos que tengamos una mejor experiencia. No puedo decirlo todavía...

He usado SVN en los últimos 3 años (procedente de VSS anteriores) y recientemente tuve que cambiar a TFS2010. La sensación general es que es más defectuoso que SVN y a excepción de la buena integración con las tareas/errores no lo veo como tener una ventaja contra SVN. La velocidad también parece ser algo más lenta que con SVN.

Si tuviera que elegir un sourcecontrol ahora todavía iría con SVN.

Con respecto a las herramientas: - AnkhSVN Visual Studio Plugin es tan bueno como el control de la fuente TFS - La tortuga es mucho mejor que la contraparte de TFS

TFS es genial, si no necesitas que no sean desarrolladores, para llegar a cosas de pm.

Nuestro servicio de asistencia necesita estar involucrado en el proceso, y simplemente no lo estaba cortando.

También la gestión de compilación en tfs 2005 por lo menos, es attrotious, y ni siquiera puede compilar vs 2008 slns. Realmente no me gusta que mi elección de control de código fuente, afecta a mis opciones de implementación, es por eso que mi equipo no es una tienda svn.

Si sólo basado en el control de código fuente, yo iría con SVN. El complemento gratuito AnkhSVN para Visual Studio se ha mejorado mucho en su nueva versión. Además, obtienes el código fuente de SVN y la documentación es genial! Cambiaron algunas cosas arcanas en el Control de código fuente de TFS 2010, y sin el código fuente puede ser muy desalentador solucionar problemas. Además, usted depende del equipo de MSDN para extraer los documentos y lo hacen en su propio horario y en su profundidad propia.

Dicho esto, TFS obviamente ofrece mucho más que control de código fuente. Es una herramienta ALM. Combinarlo con elementos de trabajo, informes, compilaciones automatizadas, registro cerrado, pruebas automatizadas, etc. puede proporcionar un valor muy rico que solo puede obtener al conectar herramientas dispares con SVN. Y, por supuesto, tener la fuente para SVN no es a prueba de fallos. Me he metido en escenarios con SVN donde todavía habría tomado semanas para calcular totalmente fuera de lo que estaba pasando.

Por lo tanto, le recomiendo que lo mire desde una perspectiva de ALM y vea si su empresa va a usar todas las características de TFS o si va a usar la mejor estrategia de su clase (por ejemplo, JIRA).

TFS por una milla.

Inadvertidamente me causa demasiados problemas con el enfoque basado en archivos SVNs. Problemas de control de código fuente que he experimentado: Problemas de TFS-0 durante 2 años SVN - perdió la cuenta...

Sí, sé que el precio de TFS lo factoriza para la mayoría de las empresas, lo que es una lástima. Los EM podrían tener mucha más cuota de mercado (y beneficios) si tuvieran un modelo de precios razonable.