2009-10-01 17 views
5

CA alguien me puede decir cuál es el rendimiento de TFS vs SVN en la WAN. Tengo un escenario en el que tenemos varios equipos configurados a través de la geografía. ¿Alguien puede ayudarme a decidir qué usar?tfs vs svn performace sobre WAN

Más sepcifically me gustaría saber sobre el rendimiento de TFS 2008. Al leer en Internet, entiendo que TFS 2005 fue realmente malo en WAN. ¿Pero quería saber si alguien ha visto alguna mejora importante en el rendimiento de TFS 2008?

Respuesta

5

TFS no está diseñado para funcionar fuera de línea (aunque es possible to work around that).

Subversion es por lo tanto una mejor opción cuando se trabaja con una conexión poco confiable/lenta. Las herramientas modernas de control de versiones como mercurial o git son aún mejores en este sentido.

Habiendo dicho eso, no estoy seguro de que la comparación sea útil. Subversion es solo un sistema de control de versiones. TFS contiene un sistema de control de versiones, servidor de compilación, rastreador de problemas, informes de proyecto y servicios de recopilación de datos, repositorio de recursos compartidos, etcétera.

2

Parece que desea considerar un sistema de control de versión distribuida (dvcs). Esto funciona muy bien ya que los desarrolladores pueden continuar trabajando sin acceso a internet y muchas otras ventajas.

Uno que parece estar ganando mucha tracción para desarrollar en Windows es GitHub combinado con para Visual Studio (dada su referencia a Tfs, asumo que esta es su configuración). Git tiene un fondo diferente, pero many MS stack projects se están moviendo hacia él, especialmente en el escenario que describe y en los de código abierto.

+1

Y, de nuevo, un sistema de control de versiones distribuidas, por lo que DVCS, no d-CVS, es la solución perfecta. Genial como siempre. -1 por la ortografía incorrecta y no responder a su pregunta. Sin embargo, un DVCS en grupos de desarrollo en todo el mundo ofrece un rendimiento mucho mejor que cualquier otra cosa. Entonces +1 por eso. Finalmente, el principal problema es la audiencia prevista: las personas a las que TFS apuntan comparten ... hm ... no tienen rasgos en común, pero son desarrolladores de software con personas segmentadas por git o hg. Entonces, ¿qué tan competentes son sus compañeros de trabajo? – gimpf

+0

@gimpf se las arregló para corregir mi error tipográfico un minuto antes de que publique comentarios;) en el público objetivo se plantea un buen punto. eso es algo que hay que hacer con respecto a git. una cierta disciplina tampoco estaría fuera de lugar. sin embargo, he usado Tfs y svn y descubrí que ambos tienen excelentes características y ambos tienen una profundidad sorprendente. no subestimes lo bueno que tiene Tfs, especialmente en lo que se refiere a servidores de compilación con tfs 2008. Sin embargo, tienes razón y es típico que solo los equipos que usan esto tengan a los que conocen las construcciones arenosas y los que simplemente usan la IU. – dove

1

La última vez que revisé, TFS no estaba optimizado para conexiones de bajo ancho de banda; por ejemplo, no envía diffs cuando actualiza una versión de archivo, sino que simplemente le envía el contenido completo del nuevo archivo (bueno, al menos lo descomprime ...).

2

Dependiendo del tamaño, la experiencia y la billetera de su equipo, una consideración para Tfs sería usar un Tfs proxy server en lugares dispares.