SVN y bases de datos de Visual FoxPro

Question

Alguien ha probado incluyendo Visual FoxPro bases de datos (ver 7) en SVN? ¿Cuáles fueron las ventajas / desventajas de incluir en? ¿Cuál es el mejor enfoque para manejar VFP dB en SMC cuando hay filas que debe incluirse en el control de código fuente?

Answer 1

Christof Wollenhaupt tiene una herramienta llamada "TwoFox" que hace un buen trabajo de conversión DBC y otros archivos de origen Fox a XML - el artículo que describe es http://www.foxpert.com/docs/cvs.en.htm . Si acaba de preguntar por soltar los archivos DBF en SVN, sin embargo, puede importar como archivos binarios, y perder la capacidad de comparar / fusionar entre las versiones, o utilizar CURSORTOXML (que estaba en 7, no?) para convertir los DBFs a XML antes de comprobar en.

Answer 2

Si bien no he usado SVN, he utilizado VFP tanto con VSS y Vault. Con ambos, agrego manualmente los archivos de control de origen, en lugar de tratar de utilizar alguna forma de integración dentro del entorno de desarrollo.

Existen básicamente dos maneras que usted puede acercarse a este:

1. Sólo tiene que añadir manualmente el DBC, .DCT, .DCX y toda la DBF, .FPT y .CDX
2. Escribir una secuencia de comandos de la base de datos para crear la estructura (utilizo una versión modificada de GenDBCX), y la creación de la escritura de los registros de datos que desee conservar en un programa o clase.

Answer 3

Mi configuración:

---

• Windows XP SP3 como una máquina virtual, en ejecución:
  • VFP 8
  • TortoiseSVN
  • SCX para convertir todos los archivos de "objeto" en texto plano archivos .

---

• Debian en una estación de trabajo P4, ejecutando:
  • Subverison través Apache2
  • Trac con ganchos en Subversion
  • respaldos nocturnos regulares tanto de la subversión y la base de datos Trac

---

Francamente, no lo verifico en las bases de datos multi-megabyte que tenemos debido a que el repositorio se hinchan hasta alrededor de 20 + GB en tamaño desde que por sí sola. Regularmente tienen tablas de 1,6 GB (y sus notas e índices) y es simplemente no vale la pena las horas perdidas esperando un 1 horas-plus comprometerse en 20Gbytes de cambios de la tabla. En su lugar, clonar los datos de nuestro sistema de producción y el uso que para "refrescar" las cosas, y reconstruir nuestro contenedor de base de datos que tienen vínculos frescas a las tablas. El proceso de "actualización" se realiza una vez al mes y lleva mucho menos tiempo, por lo general de 40 minutos; Esto contrasta con las horas que pierden todos los días .

No he tenido la necesidad de registro de entrada de datos en el repositorio, ni una sola vez. administración de esquemas se ha simplificado después de una única regla para el momento: Sólo actualizar los datos después de que todos los parches destinados a la producción han sido empujados a la producción, lo que implica el esquema para ambos entornos será consistente. Por ahora, puedo salir con la suya, a pesar de que tendrá que cambiar en el futuro ...

Si sólo necesita cambios de esquema

Si usted encuentra que usted está necesitando para comprobar en las tablas, ya que están tratando de capturar su esquema y no necesariamente las datos que contienen, es posible que desee mirar escribir una pequeña herramienta que bombea el esquema en un archivo de texto y commiting que a la cesión temporal, en lugar de enviar el fregadero de la cocina fuera para ser digeridos.

Si es absolutamente necesario comprobar en los datos

Si hay datos en las tablas que es fundamental para controlar el flujo del programa (por uso de código de datos, y no sólo los datos que se procesan por el programa), es posible considerar el recorte de sus datos al mínimo requerido y en el registro sólo las tablas resultantes del trozo , añadiendo manualmente al repositorio. Mientras que la subversión se encargará de objetos binarios, tendrá que mantener estos a un mínimo y se comprometan ellos lo menos posible para que su cesión temporal no empantanar. Asegúrese de comprobar en las tablas individuales que está buscando, y no sólo todos * .dbf, o puede estar en un rudo golpe cuando alguien trata de empujar a varios gigabytes de datos en tu repositorio porque la copia de trabajo no lo hace enmascarar todas las tablas.