SVN et Visual Foxpro Bases de données

Question

Quelqu'un at-il essayé, y compris les bases de données Visual FoxPro (ver 7) dans SVN? Quels sont les avantages / inconvénients de l'inclure dans? Quelle est la meilleure approche pour gérer VFP Db SCM quand il y a des lignes qui doivent être inclus dans le contrôle de code source?

Answer 1

Christof Wollenhaupt a un outil appelé "TwoFox" qui fait un bon travail de conversion DBC et d'autres fichiers source Fox XML - l'article décrit est http://www.foxpert.com/docs/cvs.en.htm . Si vous demandez juste de laisser tomber les fichiers DBF dans SVN, cependant, vous pouvez les importer sous forme de fichiers binaires, et perdre la capacité de comparaison / fusion entre les versions, ou utilisez CURSORTOXML (qui était en 7, non?) pour convertir les dBFs en XML avant de les vérifier dans.

Answer 2

Alors que je ne l'ai pas utilisé SVN, je l'ai utilisé VFP avec VSS et coffre-fort. Avec ces deux, j'ajouter manuellement les fichiers au contrôle de source, plutôt que d'essayer d'utiliser une certaine forme d'intégration dans l'environnement Dev.

Il y a deux façons dont vous pouvez essentiellement aborder ceci:

1. Il suffit d'ajouter manuellement le .DBC, .DCT, .DCX et tous les DBF, .FPT et .CDX
2. Ecrire un script à partir de la base de données pour créer la structure (j'utilise une version modifiée de GenDBCX) et la création de scripts de tous les enregistrements de données que vous souhaitez conserver sur un programme ou une classe.

Answer 3

Ma configuration:

---

• de Windows XPsp3 comme une machine virtuelle, fonctionnement:
  • VFP 8
  • TortoiseSVN
  • SCX pour convertir tous les fichiers "objet" dans des fichiers texte plat .

---

• Debian sur un poste de travail P4, en cours d'exécution:
  • Subverison via Apache2
  • Trac avec des crochets dans Subversion
  • sauvegardes nocturnes régulières des deux Subversion et la base de données Trac

---

Franchement, je ne vérifie pas dans les bases de données à plusieurs méga-octets que nous avons parce que le dépôt serait météorisation à environ 20+ gigaoctet taille de ce seul. Nous avons régulièrement des tables 1.6GB (et leurs notes et index) et il est tout simplement pas la peine les heures gaspillées en attente d'une 1 heure, plus COMMIT 20Gbytes des changements de table. , Nous cloner manuellement les données de notre système de production et de l'utiliser pour « rafraîchir » les choses, et reconstruire notre base de données contenant des liens pour frais aux tables. Le processus « rafraîchissement » se fait environ une fois par mois et prend beaucoup moins de temps, généralement 40 minutes; Cela contraste avec heures gaspillant chaque jour .

Je n'ai pas eu besoin de vérifier des données dans le référentiel, même une fois. Gestion du schéma a été simplifié en suivant une seule règle pour l'instant: que rafraîchir les données après tous les correctifs destinés à la production ont été poussé dans la production, ce qui implique le schéma pour les environnements seront compatibles. Pour l'instant, je peux sortir avec cela, bien que cela devra changer dans l'avenir ...

Si vous avez juste besoin de modifications du schéma

Si vous trouvez que vous êtes besoin de vérifier dans les tableaux parce que vous essayez de capturer leur schéma et pas nécessairement les données ils contiennent, vous voudrez peut-être regarder écrire un petit outil qui pompe le schéma dans un fichier texte et que commiting à la mise en pension, au lieu d'expédier la cuisine couler au large à digérer.

Si vous devez absolument vérifier dans les données

S'il y a des données dans les tableaux qui est essentiel pour contrôler le flux de programme (données en code, et non seulement les données qui sont traitées par le programme), vous pouvez envisager de couper vos données au strict minimum nécessaire et la vérification dans uniquement les tables stub résultant en les ajoutant manuellement à la mise en pension. Alors que la subversion traitera des objets binaires, vous aurez envie de les garder à une taille minimum et les engager aussi peu que possible afin que votre repo ne bog pas vers le bas. Assurez-vous de vérifier dans les tableaux individuels que vous êtes après, et pas seulement tous * .dbf, ou vous pouvez être dans un rude choc quand quelqu'un d'autre essaie de pousser plusieurs giga-octets de données dans votre repo parce que la copie de travail ne masquer toutes les tables.