¿Cuáles son los obstáculos y peligros al migrar de Visual SourceSafe a SVN?

Un cliente todavía usa Visual SourceSafe, pero después de mostrar los numerosos peligros y deficiencias de VSS, han decidido migrar de VSS a SVN Subversion.

La elección futura parece Tortoise SVN con AnkhSVN (¿buena elección?). Una ayuda de migration se describe aquí . El proyecto contiene dos sitios web, algunas aplicaciones web, varias bibliotecas de control y funciones.

Me parece que un "barrido de todos los VSS relacionados" y luego "importar en SVN" es el path a seguir. Pero los mundos no son perfectos. ¿Cuáles son los problemas que debemos tener en count y qué medidas podemos tomar para que este process se desarrolle sin problemas? ¿Hay un SVN típico para los problemas de .NET que debemos tener en count?

EDITAR: ¿ es posible de algún modo migrar el historial VSS también, o deberíamos considerar esto como un nuevo inicio solamente?

Hicimos la misma migration hace unos años y estamos muy satisfechos con los resultados. Al igual que Pino, recomiendo Tortoise SVN. AnkhSVN no pareció funcionar bien para nosotros. No sé de una forma práctica de migrar la historia.

Los principales problemas que encontramos se debieron a la naturaleza de Subversion y no a la migration. Los problemas que encontramos fueron:

  1. Aprender a trabajar con fusiones y no exclusivas.
  2. Aprendiendo que nada se elimina en Subversion. Por lo tanto, agregar el instalador con requisitos previos y luego eliminarlo no networkingucirá el tamaño del repository. Nuestro tamaño de copy de security actual es de 4GB + comprimido.
  3. Las copys de security requieren un poco de secuencias de commands, a diferencia de SourceSafe, que era una simple copy de file. svnadmin hotcopy funcionó para nosotros.
  4. Encontramos que las 'twigs de usuario' donde cada usuario tiene una twig diferente no funcionó para nosotros. Ahora tenemos un solo tronco para todos los usuarios.
  5. Fue posible comprometer un cambio sin un comentario. Puedes arreglar esto con un gancho precompromiso.
  6. Renunciar a la integración de MS Visual Studio. No es tan malo como suena.

Hay varias herramientas que pueden migrar el historial por usted. Utilizamos VSS2SVN hace unos años para hacer este mismo paso.

Puede usar múltiples clientes de subversión uno al lado del otro. Casi todos los usuarios de Windows de Subversion que conozco usan TortoiseSVN y para la integración en Visual Studio pueden usar AnkhSVN (gratuito, proveedor de SCC completo para VS 2005+ desde AnkhSVN 2.0) y VisualSVN (comercial; usa TortoiseSVN con sus propias extensiones y proporciona SCC-like características en VS 2003+).

También recomendaría instalar una installation de SVN de línea de command normal para que los guiones puedan usar.

Ver AnkhSVN vs VisualSVN para más comparaciones entre VisualSVN y AnkhSVN. Pero tenga en count que todos los clientes (TortoiseSVN, AnkhSVN, VisualSVN) son solo un shell sobre las mismas bibliotecas, por lo que puede cambiar entre ellos cuando lo desee.

Con mucho, el mayor obstáculo será educar a los desarrolladores sobre las diferencias en el uso de los sistemas de control de origen.

Checkout Editar Checkin para editar Merge Commit:

Los desarrolladores nuevos en SVN deben sentirse cómodos con la idea de que dos desarrolladores realicen cambios en un file al mismo time, y que fusionen esos cambios más adelante. Los usuarios de VSS generalmente desconocen que este estilo de control de fuente es incluso posible y sin duda no se sienten cómodos con la transición.

Enlace de proyecto a enlace de sistema de files:

VSS generalmente administra el control de origen en el nivel de proyecto y solución. El proyecto está vinculado al control de origen y cualquier cambio que ocurra en el proyecto también le sucede al control de origen. En SVN, no existe tal enlace. Todos los cambios se rastrean en el sistema de files, lo que significa que cuando agrega un nuevo file a su proyecto, también debe agregar el file al control de origen.

Por esta razón, recomiendo invertir el time para configurar un server de continuous integration para sus proyectos. Esto captará rápidamente cualquier file que se pierda de confirmaciones y evitará el incómodo escenario de que otros desarrolladores hagan un checkout y obtengan errores de compilation porque se hace reference a un file en su proyecto, pero no está presente en su control de origen.

Derivación:

Aunque puede realizar una bifurcación en VSS, rara vez he visto a alguien usarla porque es bastante complicado configurar una bifurcación, cambiar a una bifurcación y luego fusionar la bifurcación cuando termina con ella. No es necesario ramificarse para usar SVN, pero probablemente sea una de las razones principales por las que harías el cambio. Los desarrolladores deben sentirse cómodos con la idea de crear twigs donde parece apropiado y volver a fusionarlas en el Troncal.

Si sus desarrolladores ya se sienten cómodos con el uso de SVN, no debería tener ningún problema. De lo contrario, es posible que necesiten un poco de orientación para que vean las ventajas de SVN por sí mismos y, con suerte, terminen disfrutando de su uso.

Consejo número uno: Mantenga una copy de security 🙂 Número dos: Tortoise SVN – Defo el path a seguir para una máquina de Windows, además se integra con Visual Studio (A través de VisualSVN)