studio - SVN vs. Team Foundation Server

tfs 2018 download (26)

Hace unos meses, mi equipo cambió nuestro control de fuente a Apache Subversion de Visual SourceSafe , y no hemos estado más contentos.

Recientemente he estado mirando Team Foundation Server , y al menos en la superficie, parece muy impresionante. Existe una gran integración con Visual Studio y muchas herramientas excelentes para DBA, probadores, gerentes de proyectos, etc.

La diferencia más obvia entre estos dos productos es el precio. Es difícil vencer a Apache Subversion (gratis). Team Foundation Server es bastante costoso, por lo que las características adicionales realmente tendrían que patear a Subversion en los pantalones.

¿Alguien tiene experiencia práctica con ambos?
¿Cómo se comparan?
¿Vale realmente la pena el gasto de Team Foundation Server?

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

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

1) TFS está bastante estrechamente acoplado a la "forma de Visual Studio" de hacer desarrollo. Eso no quiere decir que TFS esté estrechamente acoplado al VS IDE, significa que TFS lucha por mantener el conocido paradigma de "entrada" / "salida" de Visual SourceSafe, incluso cuando ya no es un modelo apropiado. El concepto de "conversión" / "actualización" de Subversion es mucho más realista cuando tienes desarrolladores que pueden pasar tiempo desconectados de la red. TFS espera que los desarrolladores estén siempre conectados al servidor. Esa es una gran desventaja. Personalmente, creo que TFS no es 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 reconocen que su modelo de check-in / check-out conectado no es una opción atractiva 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 de "verificación" de TFS se parece un poco a un dinosaurio.

2) Costo. Quienes dicen que TFS no es costoso 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 casi todo lo que hace. ¿Eres un gerente que solo maneja los errores? Necesita una CAL de ~ $ 250 (se incluyen 5 con una licencia TFS minorista). ¿Un usuario comercial que solo quiere informar sobre sus problemas? A $ 250 CAL. 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, que no es demasiado útil en un entorno ágil y orientado al equipo. Todo esto se suma cuando tienes una organización de tamaño medio, y se vuelve difícil de justificar cuando tantos productos mejores como SVN y el costo incremental de CruiseControl.net son $ 0. (Sin embargo, para ser justos con TFS, todavía estoy esperando un buen rastreador de problemas de OSS)

3) Estructura del proyecto. En equipos grandes con un número menor de proyectos, TFS probablemente funcionará bien. Si tiene una serie de aplicaciones de línea de negocio pequeñas, desconectadas o conectadas libremente, la estructura de TFS puede comenzar a ser dominante. Por un lado, no es posible definir una taxonomía de proyectos en sí mismos: 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" suele llevar mucho tiempo y es excesivo 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 una mejor opción.

Mi opinión, por lo que vale:

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 centralmente la política con sus proyectos.
Para varios equipos pequeños, con muchos proyectos pequeños y variados, o tiendas donde el costo es un problema, o equipos que tienen desarrolladores que trabajan desconectados del control de origen, opten por SVN.

Aquí hay una versión de código abierto de VisualSVN llamada AhnkSVN . Es mucho mejor ahora que collabnet lo ha tomado.

Como Ubiguchi señala, TFS no es un producto de control de versiones. Comprar TFS con la intención de usarlo solo para 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 prácticamente orientado a "La Empresa".

También según la publicación de Ben S: no entiendo tu comentario sobre las cerraduras. No se requieren bloqueos en TFS en absoluto. Los administradores pueden configurar TFS para que funcione como VSS (características demandadas por algunos clientes "imprudentes") en "Get-Latest on Checkout", que creo que también hace un bloqueo de salida.

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

TFS hace un seguimiento de qué usuarios tienen desprotecciones en el servidor por varias razones de rendimiento (hacer que la última actualización sea más rápida) y la gestión de proyectos (me gusta ver qué desarrolladores tienen archivos desprotegidos y cuánto duran sus desprotecciones).

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 encontrado el error de fusión que informó Ben S, pero he tenido un gran éxito con ramificaciones y fusiones usando TFS.

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

Otra característica a tener en cuenta para los fanáticos de SVN que usan TFS es el puente SVN, un codeplex que permite a los usuarios usar TortiseSVN para conectarse a TFS. Un buen amigo y colega mío lo usa ampliamente y lo ama.

También me sorprende el comentario sobre la falta de línea de comando: las herramientas de línea de comando 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 2005 que claramente era un producto "Microsoft V1.0". El producto se encuentra actualmente en 2.1 con la versión 3 próximamente.

Como otros han señalado, TFS le ofrece muchas más funciones que SVN en forma de gestión de proyectos y demás. Después de haber usado ambos y trabajado con compañías 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á. 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 usado la integración SVN y casi siempre vuelvo a usar TortoiseSVN.

3) Si le gusta la idea de que las cuentas se integren con la autenticación de Windows, vaya con TFS. La manejabilidad desde ese extremo es agradable. Puede haber ganchos para SVN: no soy positivo, pero si te gusta la gestión guiada por GUI, TFS es difícil de superar.

4) Si necesita realizar un seguimiento de las métricas o tiene formas más fáciles de implementar cosas como las políticas de check-in, 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 (trabajo Java, Eclipse, etc.), vaya con SVN. Sí, hay muy buenos productos (como Teamprise) que funcionan bien con TFS. Pero a menos que los otros idiomas sean una pequeña parte de su tienda, solo quédese con SVN.

Fuera de eso, las características SCM de ambos son casi equivalentes. Ambos realizan ramificaciones y fusiones, ambos realizan registros atómicos, ambos admiten cambios de nombre y movimientos. Creo que para las personas que recién comienzan con el concepto de bifurcación y fusión, es agradable tener las ramas visibles en Source Control Explorer.

TFS realmente no es tan caro (¿$ 1200 tal vez?). En comparación con SVN es, tal vez. La integración a los servicios de informes y SharePoint es buena, pero nuevamente, si no está usando eso, entonces no importa.

Lo que diría es descargar la versión de prueba de 180 días de TFS y probarla. Ejecute una prueba de lado a lado. Creo que serás feliz sin importar en qué dirección vayas.

Después de haber usado ambos ampliamente, creo que Wedge ganó dinero al señalar que "TFS incluye seguimiento de errores, seguimiento de elementos de trabajo y otras características más allá del control de la fuente".

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

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

En mi opinión, depende de la situación y el entorno en el que se realiza el proyecto. Si solo tiene un proyecto simple y pequeño, entonces SVN es excelente. Como ya escribieron algunos, VisualSVN se integra muy bien en Visual Studio para que no tenga que hacer el check-in / check-out en el sistema de archivos nativo.

TFS es excelente para el control de versiones, pero aún mejor si realmente usa todas sus capacidades. En mi opinión, realmente vale la pena si usa, por ejemplo, los elementos de trabajo como su repositorio integrado para manejar informes de errores de clientes, solicitudes de nuevas funciones y para rastrear el progreso de su proyecto mediante la administración de tareas y el tiempo estimado, el tiempo utilizado y indicaciones de tiempo restante.
Lo que también es realmente interesante es usar la función de asociar elementos de trabajo con registros de código fuente. Vea here para más información sobre eso.

Estoy sorprendido de que alguien que haya usado Subversion en el pasado incluso tenga una necesidad / necesidad de control de 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 una troncal con desarrollo de línea principal y una rama de integración desde la que integramos los cambios y la implementación, y una rama de lanzamientos para realizar un seguimiento de los lanzamientos anteriores, es muy común y directo, pero continuamente nos encontramos con problemas.

Mis principales problemas con TFS:

La fusión es un DOLOR en comparación con la subversión.
Hay errores no corregidos. Me topé con uno sobre cambio de nombre / fusión que se conoce desde hace 2 años y nunca se lanzará una solución para 2005. Terminamos moviendo nuestra rama a una carpeta "rota" y la ignoramos ahora.
Poner bloqueos de solo lectura en tus archivos es una fricción. ¿Quién dice que necesito editar archivos por lotes y crear scripts dentro de TFS para que me "comprueben"? Subversion sabe qué archivos cambiaron. No hay bloqueos de solo lectura allí.
Velocidad. TFS es lento para una WAN, y en realidad solo se puede usar si conecto VPN a mi computadora de trabajo, lo que hace que mi experiencia de desarrollo sea realmente lenta en general.
Falta de buena integración de línea de comandos y explorador. La integración de IDE es realmente agradable para el día a día de Get-Latest, agregar archivos y registrarse, pero cuando necesita hacer cosas en muchos proyectos, es bueno tener buenas herramientas a su disposición. Y antes de que alguien salte a mi garganta diciendo que tf.exe funciona bien ... no es realmente una herramienta de línea cmd. Por ejemplo, registrar el código no debería abrir un cuadro de diálogo modal.

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

Estoy trabajando en un proyecto con 5 personas y recientemente cambiamos de SVN a TFS. Todo el proceso ha sido una pesadilla. Hemos generado código automáticamente desde XMLSpy, y TFS no reconoce archivos modificados fuera de VS2008. Las herramientas eléctricas TFS pueden escanear su pago y solucionar este problema, pero es difícil 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 podría pensar que TFS podría manejar fusiones de soluciones básicas, pero hasta ahora ese no ha sido el caso.

La interfaz de usuario integrada es muy útil, pero también tiene fallas. Si pago desde mi explorador de soluciones, a veces los archivos que se han agregado no se extraen. Si lo hago desde la ventana Team Source Control, funciona perfectamente. ¿Porqué es eso? Espero con ansias TFS en VS2010, ya que he escuchado grandes cosas al respecto, y SVN está lejos de ser perfecto, pero hubiera esperado que algunas de estas características funcionen un poco más intuitivamente.

Adán

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

Si tuviera que elegir un control de fuente ahora, todavía iría con SVN.

En cuanto a las herramientas: - AnkhSVN Visual Studio Plugin es tan bueno como el control de fuente TFS - Tortoise es mucho mejor que la contraparte TFS

He usado SVN y 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 sobre el estado del proyecto.

Lo 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 funciones que solo el control de origen. Si todo lo que necesita es control de fuente, no puede equivocarse con SVN y esta es la razón.

Servidor VisualSVN Es un servidor SVN completo con un buen complemento para administrarlo. Le permite usar la autenticación de Windows a través de la interfaz de usuario. Fácil.
Tortoise Su tortuga, dicho suficiente.
AhnkSVN Es un gran complemento SCC. Para aquellos que desean la integración completa de VS IDE, la última versión es un complemento SCC completo. Entonces ahora obtienes la integración completa de forma gratuita.

La configuración anterior es 100% gratuita y lo ayudará a superar cualquier cosa que necesite para el control de la fuente.

Me uní a un proyecto de código abierto en CodePlex, recientemente. Usan TFS para su control de fuente y tengo que decir que es absolutamente magnífico. Estoy increíblemente impresionado con eso, hasta ahora. Soy un gran admirador de la integración IDE y de lo fácil que es ramificar y etiquetar su código. Agregar una solución al control de código fuente es algo así como dos clics, si ya tiene todo configurado correctamente.

Ahora. ¿Vale la pena el alto precio? No lo creo. El beneficio de trabajar en proyectos en CodePlex es que me permite obtener la experiencia con TFS que necesito, en caso de que tenga que usarla en algún lugar más adelante. Si desea una buena integración IDE para su control de código fuente, vaya a buscar el paquete de integración de VisualSVN . Es una inversión mucho más barata obtener muchas de las mismas características (gratis en computadoras que no son de dominio, por cierto).

Mi recomendación, Team System no vale la pena. He usado ambos y después de usar Team System, intenté encontrar un reemplazo similar. Básicamente, lo que está pagando es la integración y podría argumentar el soporte de personalización, pero he podido crear un reemplazo de Team Team con un poco de tiempo e integrando herramientas juntas.

Hace poco hice una pregunta sobre lo que otros han hecho para llegar a una alternativa de Team System. También enumero las herramientas de desarrollo que utilicé para crear el reemplazo. Espero que con esta respuesta y la pregunta que hice, pueda encontrar lo que funciona para usted.

No soy un enemigo de Team System, simplemente no creo que valga la pena. Es una herramienta muy buena y si no le importa pagar el precio, utilícela. Fue la razón por la que creé el reemplazo que se me ocurrió. Quería la funcionalidad que proporcionaba Team System.

Mis 10 centavos:

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

Si solo se basara en el control de fuente, iría con SVN. El complemento gratuito AnkhSVN para Visual Studio se ha mejorado considerablemente en su nueva versión. Además, obtienes el código fuente de SVN y la documentación es excelente. Cambiaron algunas cosas arcanas en TFS 2010 Source Control, 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 según su propio horario y a su propia profundidad.

Dicho esto, TFS obviamente ofrece mucho más que control de fuente . Es una herramienta ALM . Combinarlo con elementos de trabajo, informes, compilaciones automatizadas, registro controlado , 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 de SVN no es seguro. Me metí en escenarios con SVN donde todavía me habría llevado semanas descubrir totalmente lo que estaba sucediendo.

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

Si todo lo que necesita es control de 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 Ben Schierman mencionó, junto con otros comportamientos con errores que nos empujaron hacia Subversion.

Si TFS es la decisión correcta para usted, dependerá 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 el seguimiento adicional de problemas, el elemento de trabajo y las capacidades de estadísticas del proyecto que proporciona TFS, puede valer 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 precio más bajo.

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.

Somos un pequeño equipo en el proceso de migración de SVN a TFS2010. Nuestra razón más importante para hacerlo es la integración en Visual Studio y WebAccess para el seguimiento de errores, que ahora forma parte del TFS.

@ Adam: Ojalá tengamos una mejor experiencia. No puedo decir aún ...

Somos una tienda VS.NET e implementamos:

Bugzilla para seguimiento de problemas
Apache Subversion como un repositorio de código fuente
Servidor VisualSVN para administrar SVN en el servidor
TortoiseSVN (en el Explorador de Windows) y AhnkSVN o VisualSVN (en Visual Studio) en el cliente
CruiseControl.NET para compilaciones automatizadas

Costo: $ 0 Beneficios: No tiene precio

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

TFS es atroz. En este punto, controlo la versión localmente usando SVN (con Live Mesh para copias de seguridad) porque tengo muchos problemas con TFS. El problema principal es que TFS usa 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 lo último de TFS, y dirá que todos los archivos están actualizados. Es un sistema tonto que no le garantiza que tenga la versión correcta de los archivos. Esto resulta en numerosas molestias:

Es necesario informar a TFS cuando se edita cualquier archivo, por lo que debe estar conectado al servidor en todo momento.
TFS se confunde si edita archivos fuera del IDE. Además, establece que todos los archivos sean de solo lectura en NTFS.

Si bien TFS admite la fusión, en realidad es un sistema de registro / salida. Si edita un archivo, a menudo encontrará que está bloqueado para otros desarrolladores. Hay formas de evitarlo, pero el sistema es tan complicado que siempre se encontrará con el problema. Por ejemplo, nuestros desarrolladores descubrieron que pueden sortear todos los archivos que se configuran como de solo lectura en NTFS revisando una solución completa, que establece un bloqueo exclusivo en todos los archivos. Lo hice varias veces porque la subversión tiene la misma sintaxis para el pago, que no adquiere un bloqueo.

Finalmente, Team Explorer (el cliente) es un enorme servidor TFS de 400 MB que requiere SharePoint y dos días para instalarse. El instalador de Subversion con un solo clic es de aproximadamente 30 MB e instalará el servidor por 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 costoso en términos de licencia, y con el tiempo los desarrolladores desperdiciarán despotricando en en lugar de escribir código: P

TFS es excelente para la gestión y el seguimiento de proyectos, sin embargo, creo que el control de origen no es tan bueno como SVN. Aquí están mis puntos fuertes con TFS:

Modelo de entrada / salida

Esta es una gran estafa para el control de fuente TFS. Desafortunadamente, VS desprotege automáticamente los artículos por usted, incluso si no lo desea. He estado en una situación en la que alguien revisó algunos archivos y luego se fue de vacaciones. Estaba a cargo de la reestructuración de la estructura del directorio, pero no pude hacerlo porque esa persona había extraído un montón de archivos. No hay forma en la GUI de deshacer el pago, lo que significa que tuvo que hacerse uno por uno en la línea de comando. O tenía que descubrir cómo escribir un script de Power Shell para esto.

Se requiere VS para hacer todo

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

Como algunos otros señalaron, los archivos se marcan como leídos solo si no están desprotegidos. Si lo hace editable y lo edita fuera de VS, TFS no lo reconocerá. Esto hace que editar algo fuera de VS sea molesto. Esto significa, activar VS, revisar el archivo, editarlo en otro editor, registrarse en VS.

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

Tal vez aún no lo he descubierto, pero descubrí que deshacer un conjunto de cambios era muy tedioso con TFS.
Agregar archivos al control de origen, que no son parte de una solución, es un gran dolor. El explorador de control de fuente TFS solo muestra qué archivos están en control de fuente, no cuáles no (tal vez hay una configuración en algún lugar para esto, no lo sé). Con Tortoise SVN, podría simplemente presionar Confirmar en una carpeta y seleccionar qué archivos agregar.

TFS es excelente, si no necesita personas que no sean desarrolladores, para llegar a las cosas de la tarde.

Nuestro servicio de asistencia debe estar involucrado en el proceso, y simplemente no fue suficiente.

Además, la gestión de compilación en tfs 2005, al menos, es perjudicial, y ni siquiera puede compilar vs slns 2008. Realmente no me gusta que mi elección de control de fuente afecte mis elecciones de implementación, es por eso que mi equipo no es una tienda de svn.

TFS no se trata solo del control de origen. Si usa 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 la estructura Trunk / Tags / Branches, y la relativa facilidad de cambio entre ramas. Sin embargo, la fusión parecía más fácil en TFS. Sin embargo, la interfaz de usuario de Tortoise supera a TFS, especialmente en lo que respecta a agregar un archivo a un repositorio.

TFS por una milla.

Inadvertidamente, me causé demasiados problemas con el enfoque basado en archivos SVN. Problemas de control de fuente que he experimentado: TFS - 0 problemas durante 2 años SVN - cuenta perdida ...

Sí, sé que el precio de TFS lo tiene en cuenta para la mayoría de las empresas, lo cual es una pena. MS podría tener mucha más participación en el mercado (y ganancias) si tuvieran un modelo de precios razonable.

También tenga en cuenta que TFS requiere MUCHAS más potencias del hardware del servidor. Y, como mínimo, un servidor de Windows, por supuesto, licencias.

La mejor práctica, como siguió nuestra empresa, 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 debería.

En comparación, nuestro servidor svn está instalado en un servidor Linux virtual con 256 MB de RAM y 1 CPU, y aún es varias magnitudes más rápido cuando se realizan tareas comunes como checkout-all. ¡El hardware virtual era el más bajo que vshpere podía asignar! Sin embargo, el disco es rápido (SAN).

Sugeriría que TFS requiere hardware dedicado por al menos $ 5000, mientras que el servidor svn (en Linux) puede ejecutarse con cualquier hardware que sea obsoleto para el sistema operativo basado en Windows actual.

Yo diría que realmente depende de tus necesidades. TFS es muy bueno, lo he usado 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.), vale la pena 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 tiene varias ramas o si se encuentra luchando contra alguna falta de función u otra en Subversion, entonces podría ser una buena idea cambiar. Pero salvo una buena razón para cambiar, probablemente debería evitar el impacto en el costo y la productividad de cambiar los sistemas de control de fuente.