Actualmente estoy trabajando en un entorno que todavía tiene VSS 2005. Actualmente no tengo el poder de cambiar a Subversion, TFS, etc.¿Cómo convivir con Visual Source Safe 2005?
¿Cuáles son los principales problemas que debo tener en cuenta con VSS 2005-- ¿Cómo puedo utilizarlo para tratar de guardar mis versiones y no explotar mi código fuente? Por ejemplo, ¿es mejor integrarlo con Visual Studio 2008, o simplemente usar el cliente VSS?
No haga nada complicado con VSS. Creo que muchas personas que nunca han tenido problemas con VSS simplemente lo usaban como archivos compartidos (es decir, los archivos se registran una vez y nunca se modifican). Irónicamente, usar VSS como respaldo de archivos ordinarios aumenta las probabilidades de una pérdida catastrófica.
VSS lo ahoga en una avalancha de preguntas mal formuladas. No hay una sola respuesta para cada pregunta, tendrá que detenerse y pensar en cada una. Al desconectarse de VSS, se le preguntará constantemente si desea cambiar al uso de VSS sobre IIS, si lo hace, no será obvio cómo deshacerlo.
No utilice el complemento VSS para obtener un proyecto inicial o verificar un proyecto. El complemento VSS tiende a poner sus archivos en lugares inesperados, use el cliente VSS, que es mucho más probable que le proporcione una estructura de carpetas que refleje la estructura del proyecto en VSS.
No utilice las características de compilación en la rama, no fusionar. Cree un nuevo proyecto de VSS (es decir, un nuevo conjunto de carpetas) e ingrese el código como si fuera algo completamente nuevo cuando necesita realizar una bifurcación. Use algo como incomparable si necesita simular una combinación.
No cambie el nombre de los archivos, en su lugar agregue nuevo, copie y luego elimine. Esto rompe la cadena de historial pero tiene menos agravantes
Permita el pago múltiple, pero informalmente no permita que se haga demasiado trabajo en la misma área de código, no permita que otros desarrolladores permitan que su versión se vuelva demasiado obsoleta porque entonces está intentando fusionar su versión anterior de la carpeta de trabajo y la última versión, y VSS tiende a ahogar a los desarrolladores menores en preguntas que no entienden.
No haga comprobaciones extremadamente grandes. No lo utilice en una conexión de red lenta sin productos de terceros.
Si utiliza el complemento VSS en Visual Studio, utilice periódicamente el cliente VSS para comparar y sincronizar su carpeta de trabajo, pero hágalo archivo por archivo, no en un lote.
No permita que el repositorio se vuelva demasiado grande. Dividir repositorios para trabajos no relacionados.
No se deje engañar por la contraseña de inicio de sesión. VSS no es más seguro que los permisos NTFS en la carpeta.
Cuando un desarrollador se va de la empresa, pídales que deshagan sus compras. Es un orden de magnitud más fácil deshacer pasos utilizando la misma máquina y credenciales de usuario y la misma carpeta de trabajo que usar la cuenta de administrador para deshacer los chequeos de alguien más.
También se aplican todas las mejores prácticas para cualquier sistema de control de fuente, p. compruebe las versiones sucesivas de los binarios como binaryfile.bin, no binaryfilev1.bin, binaryfilev2.bin, pero dígale a VSS que .bin o qué quiere decir binario o intentará hacer combinaciones de texto.
No he tenido más que experiencias negativas al tratar de integrar VSS con VS, por lo que recomendaría no hacerlo. Sin embargo, estábamos lidiando con proyectos de ASP.Net 1.1 en ese momento, que no tenían la buena característica de poder vivir en cualquier lugar en cualquier tipo de estructura de carpetas, y eso era principalmente donde nos encontrábamos con problemas, tratando de sincronizar el estructura del proyecto con el repositorio de VSS.
Aparte de eso, solo puedo sugerir que no ingrese el código a través de una conexión VPN que sea propensa a caerse. De hecho ... Yo sugeriría que nunca revise el código de forma remota;) Si la conexión cae en el medio de una confirmación, puede duplicar si la base de datos acaba de estar corrupta.
La última vez que lo probé (que fue hace mucho tiempo), la integración de Visual Studio jugó mal con el uso de las ramas del proyecto VSS.
Acabo de utilizar el cliente VSS.
Otras recomendaciones:
¿Cómo convivir con Visual Source Safe 2005?
Alcohol. Un montón de eso
Ejecuta un repositorio oculto SVN con un trabajo automático que comprueba los últimos archivos VSS todas las noches y los comprueba en SVN.
Cuando VSS muere (y lo hará) le dice al jefe que tenemos un segundo repositorio listo para funcionar.
¡Buena idea! Solo asegúrese de que su trabajo no haga nada que pueda corromper la base de datos de VSS, porque si lo hace, nunca lo va a olvidar :) –
¿Qué tipo de problemas tuvo? He utilizado la integración de VS con VSS durante muchos años y nunca he notado ningún problema importante con la integración. – mundeep
Creo que el problema era que cuando bifurca un proyecto (lo que significa que tiene un conjunto diferente de revisiones de los mismos archivos), entonces el archivo en el que el mapeo Visual-Studio-VSS no se cambia, es decir, es simplemente copiado en la nueva rama ... para que Visual Studio siga trabajando con la corriente principal en lugar de hacerlo con la rama que usted quería que usara. Eso fue hace mucho tiempo, así que YMMV. – ChrisW