SVN vs.Servidor Team Foundation [cerrado]

https://stackoverflow.com/questions/4219

08-06-2019
|

Pregunta

Hace unos meses, mi equipo cambió nuestro control de fuente a Subversión Apache de Visual SourceSafe, y no hemos sido más felices.

Recientemente he estado mirando Servidor de la fundación del equipo, y al menos en la superficie, parece muy impresionante.Existe una gran integración con Visual Studio y muchas herramientas excelentes para administradores de bases de datos, evaluadores, 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 caro, por lo que las funciones adicionales realmente tendrían que darle una patada en los pantalones a Subversion.

¿Alguien tiene experiencia práctica con ambos?
¿Cómo se comparan?
¿Realmente vale la pena el gasto en Team Foundation Server?

Solución

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

Ahora.¿Vale la pena el alto precio?No me parece.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 usarlo en algún lugar más adelante.Si desea una buena integración IDE para su control de fuente, vaya a buscar VisualSVN paquete de integración.Es una inversión mucho, mucho más económica obtener muchas de las mismas funciones (gratis en computadoras que no son de dominio, por cierto).

Otros consejos

Para mí, estas son las mayores diferencias entre los dos, y he usado ambos:

1) TFS está bastante estrechamente vinculado a la "forma de Visual Studio" de realizar el desarrollo. Eso no quiere decir que TFS esté estrechamente acoplado al VS IDE, significa que TFS lucha por mantener el paradigma familiar de "registro"/"registro" de Visual SourceSafe, incluso cuando realmente ya no es un modelo apropiado.El concepto de Subversion de "confirmar"/"actualizar" 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.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 el disco local debido a la estrecha integración de Visual Studio.Incluso los principales defensores de TFS admiten 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á empezando a mirar opciones de DVCS como git y Mercurial en lugar de SVN, el modelo de "comprobado" de TFS parece un poco como un dinosaurio.

2) Costo. Aquellos que dicen que TFS no es caro probablemente son tiendas muy pequeñas o no cumplen con los términos de la licencia de TFS.Necesitas una licencia de acceso de cliente para casi todo lo que haces.¿Es usted un administrador que sólo gestiona los errores?Necesita una CAL de ~$250 (hay 5 incluidas con una licencia TFS minorista).¿Un usuario empresarial que sólo quiere informar sobre sus problemas?Una cal de $250.¿Un desarrollador?$250 (A menos que tengan MSDN en cuyo caso está incluido).¿El servidor?$500 (Incluido si tienes 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 cual no es así. demasiado útil en un entorno ágil y orientado al equipo.Todo esto se suma cuando se tiene una organización de tamaño mediano y se vuelve difícil de justificar cuando el costo incremental de tantos productos de primer nivel como SVN y CruiseControl.net es de $0.(Sin embargo, para ser justos con TFS, todavía estoy esperando una en realidad buen rastreador de problemas de OSS)

3) Estructura del proyecto. En equipos grandes con una cantidad menor de proyectos, TFS probablemente funcionará bien.Si tiene varias aplicaciones de línea de negocio pequeñas, desconectadas o poco conectadas internamente, la estructura de TFS puede comenzar a volverse dominante.Por un lado, no es posible definir una taxonomía de proyectos en sí: 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 esfuerzos pequeños.Por supuesto, SVN no tiene nada de eso, ya que se centra únicamente 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 aplicar políticas de forma centralizada en sus proyectos.
Para varios equipos pequeños, con muchos proyectos variados y más pequeños, o talleres donde el costo es un problema, o equipos que tienen desarrolladores que trabajan desconectados del control de fuente, opte por SVN.

Me sorprende que alguien que haya usado Subversion en el pasado quiera o necesite 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 un tronco con desarrollo principal y una rama de integración desde donde integramos los cambios e implementamos, y una rama de lanzamientos para realizar un seguimiento de los lanzamientos anteriores, es muy común y sencilla, pero continuamente nos topamos con problemas.

Mis principales problemas con TFS:

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

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

Somos una tienda VS.NET e implementamos:

Bugzilla para seguimiento de problemas
Subversión Apache como repositorio de código fuente back-end
Servidor VisualSVN para administrar SVN en el servidor
TortugaSVN (en el Explorador de Windows) y AhnkSVN o VisualSVN (en Visual Studio) en el cliente
CruceroControl.NET para compilaciones automatizadas

Costo:Beneficios de $ 0:No tiene precio

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

Como otros han señalado, TFS le ofrece muchas más funciones que SVN en forma de gestión de proyectos y demás.Habiendo usado ambos y trabajado con empresas muy grandes en la implementación de TFS, aquí está mi granito de arena.

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, opte por 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, opte por TFS.La manejabilidad desde ese extremo es agradable.Puede que haya ganchos para SVN; no estoy seguro, pero si le gusta la administración basada en GUI, TFS es difícil de superar.

4) Si necesita realizar un seguimiento de las métricas o tiene formas más sencillas de implementar cosas como políticas de registro, opte por TFS.

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

6) Si hace algo más que .NET (trabajo en Java, Eclipse, etc.), opte por SVN.Sí, existen muy buenos productos (como Teamprise) que funcionan bien con TFS.Pero a menos que los otros idiomas sean una pequeña parte de tu tienda, quédate con SVN.

Fuera de eso, las características SCM de ambos son aproximadamente 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 bueno que las ramas sean visibles en Source Control Explorer.

TFS realmente no es tan caro ($1200 tal vez?).Comparado con SVN, quizás lo sea.La integración con los servicios de informes y SharePoint es buena, pero nuevamente, si no la estás usando, entonces no importa.

Lo que yo diría es descargar la prueba de 180 días de TFS y probarla.Realice una prueba en paralelo.Creo que serás feliz sin importar el camino que tomes.

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

También según la publicación de Ben S: no entiendo tu comentario sobre las cerraduras.Los bloqueos no son necesarios en TFS en absoluto.Los administradores pueden configurar TFS para que funcione como VSS (características exigidas por algunos clientes "imprudentes") para "Obtener lo último al finalizar la compra", lo que creo que también bloquea la compra.

Pero mediante el uso "normal" de TFS, un "pago" solicita al usuario el tipo de bloqueo, y el valor predeterminado debería ser "ninguno".Un usuario PUEDE seleccionar un bloqueo de salida (o de entrada), pero no es obligatorio.Si no quieres candados, no los uses.

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

No estoy muy familiarizado con SVN (nunca lo he usado), por lo 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 lo he pasado genial. éxito con la ramificación y fusión usando TFS.

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

Otra característica a considerar para los fanáticos de SVN que usan TFS es la Puente SVN un codeplex que permite a los usuarios usar TortiseSVN para conectarse a TFS.Un buen amigo y colega mío lo utiliza mucho y le encanta.

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 por separado de Herramientas eléctricas TFS

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 se encuentra actualmente en la versión 2.1 y la versión 3 llegará en un futuro próximo.

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 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 le indicará que todos los archivos están actualizados.Es un sistema tonto que no garantiza que tenga la versión correcta de los archivos.Esto resulta en numerosas molestias:

TFS necesita ser informado 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, configura todos los archivos como de solo lectura en NTFS.

Si bien TFS admite la fusión, en realidad es un sistema de registro/pago.Si edita un archivo, a menudo encontrará que está bloqueado para otros desarrolladores.Hay formas de solucionarlo, pero el sistema es tan complicado que siempre te encontrarás con el problema.Por ejemplo, nuestros desarrolladores descubrieron que pueden evitar que todos los archivos estén configurados en solo lectura en NTFS al probar una solución completa, que establece un bloqueo exclusivo en todos los archivos.Hice esto varias veces porque subversion tiene la misma sintaxis para el pago, que no adquiere un bloqueo.

Finalmente, Team Explorer (el cliente) tiene la friolera de 400 MB, el servidor TFS requiere SharePoint y dos días para instalarse.El instalador de un clic de Subversion pesa aproximadamente 30 MB e instalará el servidor 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 perderán despotricando sobre stackoverflow en lugar de escribir código: P

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ás pagando es la integración y se podría argumentar que es el soporte de personalización, pero he podido crear un reemplazo de Team System con un poco de tiempo e integrando herramientas juntas.

Yo recientemente hizo una pregunta sobre lo que otros han hecho para encontrar una alternativa al Team System.También enumero las herramientas de desarrollo que utilicé para crear el reemplazo.Con suerte, con esta respuesta y la pregunta que hice, puedas encontrar lo que funcione para ti.

No odio Team System, simplemente no creo que valga la pena.Es una herramienta muy buena y si no te importa pagar el precio por ella, úsala.Fue la única razón por la que creé el reemplazo que se me ocurrió.Quería la funcionalidad que proporcionaba Team System.

Aquí hay una versión de código abierto de VisualSVN llamada ankhsvn.Es mucho mejor ahora que Collabnet se hizo cargo.

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 ni 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 otros errores de comportamiento que nos empujaron hacia Subversion.

Que TFS sea la opción adecuada 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 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 brindan el tipo de supervisión que un gerente de proyecto o programa podría ofrecer a un precio más bajo.

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

Lo he usado tanto en el trabajo como en casa.Ambos son geniales por derecho propio.Sin embargo, la única vez que recomendaría usar TFS es si va a utilizar más funciones además del control de fuente.Si todo lo que necesita es control de fuente, no puede equivocarse con SVN y este es el motivo.

Servidor VisualSVN Es un servidor SVN completo con un buen complemento para administrarlo.Le permite utilizar la autenticación de Windows directamente a través de la interfaz de usuario.Fácil.
Tortuga Es una tortuga, ya he dicho suficiente.
ankhsvn Es un gran complemento SCC.Para aquellos que desean una integración completa con VS IDE, la última versión es un complemento SCC completo.Ahora obtienes una integración completa y gratuita.

La configuración anterior es 100% gratuita y le ayudará a realizar todo lo que necesite para el control de fuente.

TFS no se trata sólo de control de fuente.Si utiliza todo el paquete que ofrece TFS, seguimiento de errores, compilaciones, informes, etc., TFS es una opción bastante sólida (sin duda, mejor que Rational).TFS también se integra bien con Active Directory.

Aunque si solo estás hablando de SCM, prefiero SubVersion.Realmente no me gusta la integración IDE.También me gusta la convención de SVN de estructura de Troncales/Etiquetas/Sucursales y su relativa facilidad para cambiar 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.

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 funciones, puede que no sea necesario.Si necesita esas funciones (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 funciones que escapan al control de origen.Si tiene varias ramas o si se encuentra luchando contra alguna falta de característica u otra en Subversion, entonces podría ser una buena idea cambiar.Pero, salvo que haya una buena razón para cambiar, probablemente debería evitar el impacto en costos y productividad que supone cambiar los sistemas de control de fuente.

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

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

Si desea realizar un seguimiento de elementos de trabajo y errores junto con su control de fuente, entonces puede optar por TFS o utilizar SVN y algunas 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 como disculpa por abusar de tantos desarrolladores con VSS a lo largo de los años.

He usado tanto SVN como TFS.La principal ventaja de utilizar TFS es su estrecha integración con Visual Studio.El seguimiento de errores y el seguimiento de tareas estarán todos en un solo lugar.Y los informes generados para estos elementos ayudarán a las partes interesadas a mantenerse informadas sobre el 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 archivos modificados fuera de VS2008.TFS Power Tools puede escanear su caja y solucionar este problema, pero es complicado tener que recordar usar estas herramientas.Otro problema con el que nos encontramos constantemente es la herramienta de combinación predeterminada en TFS.Es, con diferencia, la peor herramienta de fusión que he utilizado.Uno podría pensar que TFS sería capaz de 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 fallos.Si pago desde mi explorador de soluciones, a veces los archivos que se agregaron no se retiran.Si lo hago desde la ventana de Team Source Control funciona perfectamente.¿Porqué es eso?Espero con ansias TFS en VS2010 porque he escuchado cosas maravillosas sobre él y SVN está lejos de ser perfecto, pero hubiera esperado que algunas de estas características funcionaran de manera un poco más intuitiva.

Adán

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

Modelo de check-in/check-out

Esta es una gran desventaja para el control de fuente TFS.Desafortunadamente, VS verifica automáticamente los artículos por usted, incluso si usted 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 reestructurar la estructura del directorio, pero no pude porque esa persona tenía un montón de archivos desprotegidos.No hay forma en la GUI de deshacer el pago, lo que significaba que debía hacerse uno por uno en la línea de comando.O tuve 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 me llevó unos segundos con SVN ahora me lleva un minuto.

Como otros señalaron, los archivos se marcan como de solo lectura si no están desprotegidos.Si lo hace escribible y lo edita fuera de VS, TFS no lo reconocerá.Esto hace que editar algo fuera de VS sea molesto.Esto significa iniciar VS, verificar el archivo, editarlo con otro editor, registrar VS.

Algunas operaciones que eran fáciles en SVN ahora son una molestia

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

Actualmente estoy liderando el esfuerzo para evaluar TFS en mi empresa frente a Rational Suite, que es lo que utilizamos 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 e incluso 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 ÉPICO!- la instalación es fácil para perros.La gestió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 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 evolución 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!Aunque todavía cuesta demasiado :(

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

La mejor práctica, como siguió nuestra empresa, es utilizar 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 sigue siendo varias magnitudes más rápido al realizar tareas comunes como pagar todo.¡El hardware virtual era el más bajo que Vshpere podía asignar!Sin embargo, el disco es rápido (SAN).

Yo sugeriría que TFS requiere hardware dedicado por al menos $ 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 realiza el proyecto.Si solo tiene un proyecto pequeño y simple, entonces SVN es excelente.Como algunos ya escribieron, VisualSVN se integra muy bien en Visual Studio s.t.no es necesario realizar el registro/desprotección a través del sistema de archivos nativo.

TFS es excelente para el control de versiones, pero aún mejor si realmente usas todas sus capacidades.En mi opinión, realmente vale la pena si utiliza, por ejemplo, los elementos de trabajo como su repositorio integrado para manejar los informes de errores de los clientes, las solicitudes de nuevas funciones y para realizar un seguimiento del progreso de su proyecto mediante la gestión de tareas y el tiempo estimado correspondiente, el tiempo utilizado y indicaciones de tiempo restante.
Lo que también es realmente interesante es utilizar la función de asociar elementos de trabajo con registros de código fuente.Ver aquí para más información sobre eso.

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

@Adán:Ojalá tengamos una mejor experiencia.No puedo decirlo todavía...

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

Si tuviera que elegir un control de fuente ahora, seguiría usando SVN.

En cuanto a herramientas:- El complemento Ankhsvn Visual Studio es tan bueno como el control de fuente TFS - Tortoise es mucho mejor que la contraparte de TFS

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

Nuestro servicio de asistencia técnica debe participar en el proceso, y simplemente no fue suficiente.

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

Si se justo Según el control de fuente, elegiría SVN.El complemento gratuito AnkhSVN para Visual Studio se ha mejorado enormemente 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 resultar muy difícil solucionar el problema.Además, usted depende del equipo de MSDN para generar los documentos y ellos lo hacen según su propio cronograma y en su propia profundidad.

Habiendo dicho eso, TFS obviamente ofrece mucho más que control de fuente.Es un ALMA herramienta.Combinándolo con elementos de trabajo, informes, compilaciones automatizadas, check-in cerrado, pruebas automatizadas, etc.puede proporcionar un valor muy rico que solo se puede obtener conectando herramientas dispares con SVN.Y, por supuesto, tener la fuente de SVN no es un sistema de seguridad.Me metí en escenarios con SVN en los que aún me habrían llevado semanas descubrir por completo qué estaba pasando.

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 va a hacerlo con la mejor estrategia de su clase (p. ej.JIRA).

TFS por una milla.

Sin darme cuenta, me causo 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 - Contejo perdido ...

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

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow