2009-02-02 16 views
5

Actualmente mi equipo usa Visual Sourcesafe, y estando muy familiarizado con lo horrible que es la GUI de primera mano y habiendo escuchado a la aficionada de Internet sobre lo poco confiable que es, he estado tratando de impulsar un movimiento a SVN.¿Replicar la ablity de enlace de Sourcesafe en SVN u otros sistemas de control de versiones?

Hoy estaba hablando con el gerente sobre el movimiento final, que él admite, y me preguntó si era posible crear enlaces de estilo de sourcesafe en SVN. Los enlaces, para personas que no están familiarizadas con sourcesafe, funcionan de la misma manera conceptual que los enlaces de archivos en Linux. Los usamos para vincular código compartido/bibliotecas entre proyectos. Le expliqué que no había forma de crear enlaces usando SVN, y él mencionó que ese podría ser un importante punto de fricción en la migración.

Le dije que en mi SVN local (que mantengo para facilitar mi desarrollo, comprobando solo periódicamente en sourcesafe), coloco códigos/bibliotecas compartidas en una ubicación y remito ANT a esa ubicación. Sin embargo, tuve la sensación de que no estaba muy impresionado con esta solución, ya que agrega complejidad a las tareas de ANT. Personalmente creo que vale la pena tener un script ANT un poco más complejo que tener un montón de archivos de enlace en control de fuente, pero realmente es una cuestión de a qué paradigma se suscribe.

Tengo curiosidad acerca de cómo los desarrolladores en general trabajan alrededor de esta limitación, y ¿hay sistemas de control de fuente más nuevos como los enlaces de soporte de Git y Mercurial?

Respuesta

8

Busque en svn:externals propiedades.

+0

+1 me gané. Esto es bueno porque puede hacer referencia a otros repos en otros servidores si es necesario; es bastante poderoso –

+0

¿Cuáles serían las limitaciones aquí en comparación con los enlaces? –

+0

En su mayoría, solo nombrar restricciones (espacios/puntos las rompen) y una interfaz de usuario demasiado complicada/manual. De lo contrario, es casi idéntico. –

3

Utilizamos TFS para el control de versiones, y TFS tampoco tiene la función de enlaces VSS. Hemos eliminado todos nuestros archivos vinculados. Todos los archivos de clase que se vincularon previamente se han colocado en bibliotecas de clase que se comparten en nuestros otros proyectos como referencias de proyectos compartidos en la solución. Entonces, en esencia, usted comparte bibliotecas, no archivos de clase.

Hubo un poco de un proceso de ajuste acostumbrándose a esto, pero no he perdido enlaces desde entonces. Realmente promueve una mejor práctica de diseño teniendo tu código configurado así. Tener las clases utilizadas en un solo proyecto ayuda a evitar los cambios ya que es mucho más fácil probar el impacto del cambio (usando enlaces que ni siquiera sabrás si causaste un problema de compilación con un cambio). Además, algunas de las características de los sistemas de control de fuente más agradables (como una ramificación robusta y soporte de fusión) funcionan mucho mejor cuando no tiene que preocuparse por los archivos vinculados.

-1

Los enlaces son útiles cuando los originales deben ser compartidos entre diferentes plataformas (.NET, Silverlight, .NetCF) porque los archivos fuente pueden ser iguales y por lo tanto pueden ser compartidos, pero las bibliotecas compilados no se pueden compartir entre estas plataformas.

Cuestiones relacionadas