Usando Subversion con Visual Basic 6

Question

Mi equipo se está moviendo de Visual SourceSafe a Subversion pronto, mientras desarrolla / apoya un proyecto heredado en Visual Basic 6.0, así que tengo un par de preguntas:

• ¿Cuál es la mejor herramienta para la integración de Subversion IDE en Visual Studio 6? (o no vale la pena ...)
• ¿Existen prácticas recomendadas para usar Subversion con Visual Basic 6.0? (tipos de archivo a ignorar, etc.)

Answer 1

Estoy de acuerdo en que Tortoise SVN en el Explorador de Windows sería la mejor manera de usar SVN con VB6.

El cambio más grande que encontrará al migrar a SVN es la idea de " Echa un vistazo " y " Registrarse " no son exactamente lo mismo que " Actualizar " y "Comprometerse". . . por lo tanto, cualquier integración IDE con VB6 es limitada porque VB6 es compatible con MSSCCI, un mecanismo de check-out / check-in. Una vez utilicé TamTam SVN ( http://www.daveswebsite.com/software/tamtamsvn/index .shtml ) con Visual Studio 2003, pero se detuvo porque lo encontré limitante. Fusionar / ramificar / culpar, etc. son características muy poderosas que Tortoise SVN proporciona que no estaban en TamTam. Tigris también tiene http://svnvb6.tigris.org/ , pero no lo he probado.

Una vez más, aunque es muy probable que obtenga un IDE para trabajar con VB6, no lo recomendaría, ya que la mayor ventaja de migrar a SVN es romper la filosofía de entrada y salida de Source Safe.

Answer 2

Dado que Subversion utiliza un ciclo de actualización / edición / confirmación (en lugar de checkin / checkout), deberá tener especial cuidado con los archivos binarios. La mayoría de los formularios en VB6 consisten en dos archivos: MyForm.frm y MyForm.frx. Los archivos * .frx son binarios y, por lo tanto, no se pueden combinar.

Dado eso, configuraría Subversion para requerir " bloqueo " en archivos .frx. Esto significa que solo una persona puede revisar el archivo a la vez. Al hacerlo, exigirá que solo un desarrollador pueda modificar estos archivos a la vez, y siempre queda claro quién es esa persona actualmente. Si no haces esto, te estás preparando para algunos dolores de cabeza importantes.

Answer 3

Tipos de archivos a ignorar:

* .vbw
Archivo de área de trabajo que se genera automáticamente al cerrar un proyecto y que contiene los archivos que tiene abiertos, etc.

MSSCCPRJ.SCC
El archivo de estado de control de origen generado por el IDE de VB6 (si elige la solución de control de SVN en el Explorador de Windows, debe deshabilitar el complemento de control de origen en VB6 y esto no se generará).

* .log
Se trata de archivos generados si algo falla al cargar una GUI de formulario. El archivo se encuentra en el mismo lugar que el archivo de formulario con el nombre igual al archivo de formulario.
Ejemplo de : MyForm.frm genera MyForm.log .

Por supuesto, solo debe hacer esto si no tiene los archivos de registro que necesita en el control de origen ...

Answer 4

  

Dependiendo de cuánto planee hacer en estos proyectos heredados, consideraría no cambiar.

Realmente te aconsejaría que cambies a SVN. Sé de algunos proyectos que perdieron el código fuente porque la base de datos de VSS se corrompió.

Creo que hay herramientas que realizan la migración de SourceSafe a SVN. (Sí, una rápida búsqueda en Google lo confirmó). De esa forma, no perdería el historial de revisiones.

Answer 5

Mi conjetura sería no molestarse con la integración y simplemente usar Tortoise SVN en el Explorador de Windows.

En cuanto a los tipos de archivos que se deben ignorar, haga una prueba, compruebe, genere y vea si se modificó algún archivo (para Visual Studio moderno tiendo a ignorar los archivos .suo)

Answer 6

Para el lado del servidor, VisualSVN Server, es una solución super simple, lo estamos ejecutando en un vmware virtual, y su zumbido a lo largo.

Si usted es un tipo de línea de comandos, realmente me gusta la interfaz de línea de comandos para svn, me resulta menos confuso llegar a ciertas acciones que a la tortuga, como el estado de la carpeta. Pero si usted es un fanático de los exploradores, la tortuga es más que adecuada, ya que proviene de un mundo de fuentes seguras.

Las principales cosas a ignorar son:

• Artefactos reproducibles (dll, pdb, exe)
• Configuración específica del entorno (es decir, el archivo de configuración para vs, archivo csproj.user, archivos .suo)

Answer 7

Dependiendo de cuánto planee hacer en estos proyectos heredados, consideraría no cambiar.

Al excavar a través del código heredado, realmente ayuda tener toda la historia y la culpa. SVN es mucho mejor que VSS, pero perderás el historial cuando cambies.

Si va a ser un gran desarrollo continuo en VB6, entonces puede que valga la pena cambiar a SVN, pero si va a hacer mucho en el futuro, ¿también vale la pena revisar el proyecto?

Tengo un problema similar, solo los proyectos heredados están en Delphi. Si estuvieran en VB6, creo que consideraría 'actualizarlos' a VB.Net, solo por facilidad de mantenimiento.