De SourceSafe a Team Foundation Server

Question

Nuestro equipo desea pasar de Visual SourceSafe (VSS) al Team Foundation Server (TFS). Sé que TFS es mucho más que un sistema de control de versiones, pero por primera vez me gustaría usarlo de esta manera.

Actualmente nuestros proyectos están organizados en una única solución que consiste en la parte compartida (biblioteca común) y muchos proyectos de clientes.

¿Existe algún tipo de guía de migración que describa este desafío? ¿O TFS impone sus propios escenarios de uso (versiones de proyectos, lanzamientos, etc.)?

Answer 1

TFS sin duda tiene mucho más potencial que simplemente como un repositorio de código fuente, pero es bastante comprensible por qué desea migrar control de código fuente en primer lugar.

La utilidad de migración de elección es generalmente VSSConverter.exe que le permite mapear rutas de VSS a rutas de control de origen de Team Project y está bastante bien documentada en este tutorial here.

Hay otra herramienta (TFS Migration and Synchronization Toolkit) disponible en CodePlex, pero cuando comparé las dos, determiné que VSSConverter se ha utilizado más ampliamente y creo que generalmente se acepta como la herramienta preferida para las migraciones de VSS.

Parece que hay algunas respuestas más on this thread here también.

Ahora, la pregunta que creo que es realmente pregunta es más sobre orientación sobre la creación de proyectos de equipo y la estructuración?

Esto es un poco más difícil de responder sin saber más acerca de su circunstancia específica. Patrones y prácticas publicó un book on CodePlex called the TFS Guide que podría ayudar; describe, entre muchas cosas, una estructura de control de origen de Team Project sugerida. Puede ser útil para darle alguna orientación sobre cómo migrar y/o reasignar la estructura de su solución.

En cuanto a las versiones y las ramificaciones, revise este site here on branching guidance - no es una mala descripción de algunas técnicas comunes de administración de ramificación/liberación utilizando TFS.

Si supera toda esa lectura, ¡estará realmente al tanto de la mayoría de las bases fundamentales de TFS!

Answer 2

TFS y VSS son bestias radicalmente diferentes.

Dicho esto, los principales problemas para pasar de VSS a TFS generalmente se tienen en cuenta en el desarrollador.

Echa un vistazo a los siguientes blogs:

TFS from a VSS User's perspective: http://blogs.msdn.com/robcaron/archive/2006/10/29/901115.aspx

Y, por supuesto, el original http://sstjean.blogspot.com/2006/10/document-from-vss-to-tfs-introduction.html

Answer 3

(Siéntase libre de downvote pero ...) Si lo que busca un mejor control de la fuente entonces TFS es superávit en mi humilde opinión. Te recomiendo que busques en Subversion. VisualSVN es un plug-in excelente ($ 49) para Visual Studio que funciona a la perfección junto con posiblemente el mejor cliente SVN TortoiseSVN. Además, proporcionan un paquete de Windows gratuito y fácil de instalar, del lado del servidor Subversion llamado Servidor VisualSVN.

Para aprender todo sobre la forma de trabajar de Subversion, existe la gran Red Bean book.

(No afiliado con VisualSVN, sólo un fanboy de Subversion)

Answer 4

Cuando cambiamos de Sourcesafe a TFS2005, el mayor obstáculo fueron los archivos compartidos de Sourcesafe, el enfoque "Obtener lo último al finalizar la compra" y el "soporte" de fusión/rama en SourceSafe. Todo el mundo temía ramificarse y fusionarse en Sourcesafe y le tomó un tiempo convencer a todos sus colegas de que no es tan malo con TFS.

Decidimos no migrar archivos de Sourcesafe. Usamos TFS2005 para un nuevo proyecto y mantuvimos las cosas viejas en Sourcesafe. No queríamos mantener la estructura de proyecto y carpeta que había crecido a lo largo de los años y que estaba bastante desorganizada.

Lo viejo es historia ahora y hacemos todo el trabajo de desarrollo con TFS2008.