Visual Source Safe -> TFS Migration

Question

Por aquí hemos estado trabajando con varios repositorios de Visual Source Safe durante aproximadamente 10 años más o menos.

Ahora quiero deshacerme de sourcesafe y pasar a Team Foundation Server.

¿Tiene algún consejo o trucos para mí antes de embarcarme en esta migración? ¿De qué tengo que tener cuidado?

Estoy seguro de que esta migración significará que nuestros hábitos de trabajo tendrán que modificarse de alguna manera. ¿Crees que estos cambios podrían ser un problema para la organización? Piense en un grupo de aproximadamente 20 desarrolladores .NET en un solo sitio.

Answer 1

Acabo de buscar en Google, pero this walkthrough parece una buena referencia, y menciona la herramienta VSSConverter que debería ayudar a que la migración sea lo menos dolorosa posible.

Me gustaría recomendar una cosa sin embargo: Copia de seguridad. Respalda todo antes de hacer esto. Si algo sale mal, es mejor estar seguro que lamentar.

Mis enlaces no aparecen. Esta es la dirección: http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx

Answer 2

Existen varias formas diferentes de migrar. La herramienta va a tirar de su historia, etc. terminado, pero la manera más pragmática y sencilla es bloquear VSS como un archivo de la historia y empezar de cero:

1. Haga que todos comprobar en todos los cambios en VSS, asegurarse de que todo se basa, etc.
2. Establecer las bases de datos de VSS a "bloqueado" (derechos de sólo lectura para todos los usuarios)
3. Obtener la última en la base de datos de VSS en un conjunto "limpia" de carpetas en una estación de trabajo
4. compruebe todos los puntos archivos en TFS desde la estación de trabajo

Para cualquier historial anterior a la conversión, la gente necesita ir a VSS, pero después de una semana o dos es muy poco probable que suceda con tanta frecuencia. Y sabe que el historial en VSS es preciso y no está dañado por el proceso de conversión.

Answer 3

Tenga en cuenta que TFS no admite el uso compartido de archivos entre diferentes proyectos, como lo hace VSS. Si tiene alguno de esos archivos compartidos, el vínculo entre ellos se romperá durante la migración, lo que resultará en archivos inicialmente idénticos, pero ahora distintos en cada proyecto. Las actualizaciones de uno de estos archivos en TFS ya no se propagarán a las copias en los otros proyectos.

Answer 4

Actualmente estamos en el proceso de hacer esto en mi trabajo diario. En realidad estamos haciendo el cambio en aproximadamente un mes. Soy parte principal de la migración y una gran parte de por qué nos estamos saliendo de SourceSafe. Para ayudar en la migración, utilicé el Visual Studio® Team System 2008 Team Foundation Server and Team Suite VPC Image. Fue muy útil. Desde el principio, la imagen contiene una instalación TFS completa para que juegues y demuestres con ella. También incluye Hands on Labs y uno de los laboratorios ejecuta la herramienta de migración VSS -> TFS. Si tiene una suscripción a MSDN, una vez que haya jugado con la imagen, el siguiente paso sería instalar la edición TFS Small Team que viene con su suscripción.

Una cosa a tener en cuenta es asegurarse de obtener los Service Pack más recientes para Visual Studio 2008 y .NET Framework instalados en la imagen. Los service packs arreglaron algunos errores molestos y definitivamente aumentaron la usabilidad del sistema. Tenemos una base de datos SourceSafe escasamente grande con más de 90 proyectos y la herramienta de migración tardó aproximadamente 32 horas en completarse.Primero hice una copia de seguridad de nuestra base de datos de sourcessafe para probar. Luego realicé la migración en la base de datos de prueba de sourcesafe. Después, revisé el árbol de fuentes en TFS y todo se transfirió bien. Mantuvimos todo el historial de nuestros archivos fuente de VSS, que fue genial. No hay necesidad de mantener esa apestosa base de datos VSS después de que entremos en funcionamiento.

Estamos llevando a cabo la migración en pasos. Primero, el control de fuente y dejar que nuestros desarrolladores se acostumbren a usarlo. Luego, migraremos el QA y los analistas de negocios para usar las funciones de seguimiento del ítem de trabajo.

Mi consejo es realizar la migración en pasos. No hagas demasiado al mismo tiempo. Dé tiempo a las personas que usarán el sistema para entrenar.

Answer 5

Buena orientación de mi antiguo colega Guy Starbuck. Otra cosa que debe agregarse con ese enfoque: es posible que haya decidido con el tiempo que desea refactorizar la forma en que se organiza su aplicación (carpetas, etc.) y esto le dará la oportunidad de hacerlo.

He estado en situaciones en las que organizamos una solución al azar sin pensar (y mucho menos cambios importantes en la aplicación) que llevaron a un deseo de organizar las cosas de manera diferente - y el cambio de VSS a TFS es una gran oportunidad para hacer asi que.

En cuanto a la pregunta original:

Y: Esta migración con seguridad significa que nuestros hábitos de trabajo tienen que ser modificados de alguna manera. ¿Crees que estos cambios podrían ser un problema para la organización? Piense en un grupo de aproximadamente 20 desarrolladores de .net, en un solo sitio

Yo diría que sí, sus hábitos de trabajo cambiarán pero mucho más para mejor.

1. No debe usar bloqueos "Check-out" y "Get-Latest on Check-out".
2. Ahora puede efectivamente Branch y Merge
3. Ahora tendrá "Changesets", todos los archivos registrados al mismo tiempo se agruparán. Esto hace que el seguimiento histórico de cambios sea mucho más fácil, pero lo más importante es que las reversiones son mucho más sencillas (es decir, busca todos los archivos registrados al mismo tiempo y los retrotrae)
4. Asociando registros a elementos de trabajo. ¡No pase por alto los artículos de trabajo! El mayor error que puede cometer es usar solo TFS como reemplazo de VSS. Las funciones de compilación y gestión de proyectos son excelentes; pagaste por ellas. ¡ÚSALAS!

En cuanto a los detalles sobre cómo va a cambiar su experiencia, otro ex colega mío (y Team System MVP) Steve St. Jean escribió un artículo detallado sobre las diferencias: From VSS to TFS

Answer 6

Si decide utilice la herramienta VSSConverter.exe que se envía con Visual Studio Team Foundation Server, luego debe instalar TFS 2008 SP1 primero ya que incluye una serie de mejoras como se detalla en on this blog by the migration tools team.

Algunas de las características clave de la liberación incluyen:

Eliminación de espacio de nombres en conflicto.I anteriormente escribí sobre esto como "el problema de cambiar el nombre " y hemos corregido el convertidor para migrar correctamente los archivos con espacios de nombres superpuestos. Esto fue el mayor punto de dolor para la mayoría de los usuarios tratando de utilizar las versiones anteriores de la herramienta .

Reenlace de solución automática. En esta última versión, los archivos de la solución VS se actualizarán automáticamente a la versión 9.0 y se devolverán en al control de versiones. Anteriormente, los usuarios estaban obligados a hacerlo manualmente.

Corrección de la marca de tiempo inconsistencias. El uso de marcas de tiempo por cliente VSS puede conducir a revisiones que se registran en el orden opuesto que, efectivamente, se produjeron en . La herramienta reconoce ahora esta cuestión y continúa migrando cambios donde sería previamente fallar.

Mejorado el registro. Aunque hemos solucionado un montón de problemas, proporcionando mejor, el registro más detallado será para ayudar a los usuarios que se topan con los problemas a diagnosticar los problemas.

Answer 7

VSS Converter es una solución lejos de ser perfecta. Y existen diferencias significativas entre la versión 2005SP1 del convertidor.

Por ejemplo, en un VSS DB que ha estado en uso durante mucho tiempo, habrá una gran cantidad de usuarios contribuyendo a VSS. Muchos de estos usuarios habrán abandonado la organización hace mucho tiempo y, por lo tanto, ya no tendrán cuentas de dominio. TFS requiere asignar usuarios de VSS a cuentas de dominio, por lo que deberá decidir si asigna usuarios antiguos a una única cuenta de dominio "ficticia" o a un miembro del equipo actual.

Además, VSS Converter 2008 requiere que estas cuentas de dominio sean cuentas TFS válidas. Mientras que el convertidor de 2005 no hace cumplir esto.

Si su historial de VSS contiene movimientos significativos de la carpeta, entonces es probable que pierda todo el historial antes de este movimiento. Por ejemplo, si mueve una carpeta a una nueva ubicación y luego elimina la matriz anterior, perderá todo el historial. Consulte este artículo para obtener más información: http://msdn.microsoft.com/en-us/library/ms253166.aspx

En una migración en la que participé, teníamos una base de datos de VSS de 10 años que perdió todo el historial hace 6 meses. Esto se debió a una importante limpieza que tuvo lugar hace 6 meses.

Answer 8

TFS conversion tool < - Utilice esta

He usado esta herramienta desde hace ya algunas veces, los resultados son bastante satisfatory ya que viene con la historia de los conjuntos de cambios de SourceSafe si lo desea también.

De todos modos, utilizando esta herramienta siempre debe prestar atención a los errores y advertencias en el registro, y comprobar si todo está bien construido/pasado bien.

Se recomienda ejecutar también un análisis en SS antes de ejecutar esto.

creo que sirve