قواعد بيانات SVN و Visual FoxPro

Question

وقد حاول أي شخص بما في ذلك قواعد بيانات Visual FoxPro (Ver 7) في SVN؟ ما هي مزايا / عيوب بما في ذلك ذلك؟ ما هو أفضل نهج للتعامل مع VFP DB في SCM عند وجود صفوف يجب تضمينه في التحكم المصدر؟

Answer 1

لدى Christof Wollenhaupt أداة تسمى "TWOFOX" التي تقوم بعمل جيد تحويل DBCS وملفات مصدر الثعلب الأخرى إلى XML - مقالة تصفها http://www.foxpert.com/docs/cvs.en.htm.. وبعد إذا كنت تسأل فقط عن إسقاط ملفات DBF إلى SVN، فيمكنك استيرادها كملفات ثنائية، وفقدان القدرة على مقارنة / دمج بين الإصدارات، أو استخدام Cursortoxml (الذي كان في 7، لم يكن ذلك؟) لتحويل DBFS إلى XML قبل التحقق منها.

Answer 2

في حين أنني لم أستخدم SVN، استخدمت VFP مع كل من VSS و Vault. مع كل من هذه، أضف الملفات يدويا إلى عنصر التحكم المصدر، بدلا من محاولة استخدام بعض أشكال التكامل داخل بيئة DEV.

هناك أساسي طريقتان يمكنك التعامل مع هذا:

1. فقط إضافة .DBC، .DCT، .DCX وجميع .DBF، .fpt و .cdx
2. اكتب نصا من قاعدة البيانات لإنشاء الهيكل (يمكنني استخدام إصدار معدلة من GENDBCX)، وإنشاء البرنامج النصي لأي سجلات بيانات تريد الحفاظ عليها في برنامج أو فئة.

Answer 3

الإعداد الخاص بي:

---

• Windows XPSP3 كجهاز افتراضي، يعمل:
  • VFP 8.
  • السلاحف
  • SCX لتحويل جميع "ملفات الكائنات" إلى ملفات نصية مسطحة.

---

• ديبيان على محطة عمل P4، تشغيل:
  • secverison عبر Apache2.
  • TRAC مع السنانير في التخريب
  • النسخ الاحتياطية الليلي العادية لكل من التخريب وقاعدة بيانات TRAC

---

بصراحة، أنا لا تحقق في قواعد بيانات متعددة ميغابايت أن لدينا لأن المستودع سوف ينفد إلى حوالي 20+ غيغيوم في الحجم من ذلك وحده. لدينا بانتظام طاولات 1.6 جيجابايت (ومذكراتها ومؤشراتها) وهي ليست فقط تستحق ساعات هدرت في انتظار ارتكاب 1 ساعة بالإضافة إلى 20gbytes من تغييرات الجدول. بدلا من ذلك، ننسخ البيانات من نظام الإنتاج لدينا واستخدام ذلك إلى "تحديث" الأشياء، وإعادة بناء حاوية قاعدة البيانات الخاصة بنا للحصول على روابط جديدة للجداول. تتم عملية "تحديث" حوالي مرة واحدة في الشهر وتستغرق وقتا أقل بكثير، عادة 40 دقيقة؛ على النقيض من ذلك مع هدر ساعات كل يوم.

ليس لدي حاجة للتحقق في البيانات في المستودع، حتى مرة واحدة. تم تبسيط إدارة المخطط باتباع قاعدة واحدة في الوقت الحالي: تحديث البيانات فقط بعد أن تم دفع جميع التصحيحات التي تعني الإنتاج إلى الإنتاج، مما يعني أن المخطط لكلا البيئة ستكون متسقة. في الوقت الحالي، يمكنني الابتعاد عن هذا، على الرغم من أن ذلك سيكون يجب أن يتغير في المستقبل ...

إذا كنت بحاجة فقط إلى تغييرات المخطط

إذا وجدت أنك تحتاج إلى التحقق من الجداول لأنك تحاول التقاطها مخطط وليس بالضرورة بيانات تحتوي على ذلك، قد ترغب في إلقاء نظرة على كتابة أداة صغيرة تضخ المخطط إلى ملف نصي وتشكل على الريبو، بدلا من شحن مغسلة المطبخ ليتم هضمها.

إذا كنت بحاجة مطلقا للتحقق في البيانات

إذا كانت هناك بيانات في الجداول التي تعتبر مهمة للتحكم في تدفق البرنامج (بيانات البيانات، وليس فقط البيانات التي تتم معالجتها بواسطة البرنامج)، فقد تفكر في تقليم بياناتك إلى الحد الأدنى المطلوب والتحقق منها مجرد طاولات الروتين الناتجة عن طريق إضافة لهم يدويا إلى الريبو. في حين أن التخريب سوف يعالج الكائنات الثنائية، سترغب في الحفاظ على الحد الأدنى للحجم وارتكبها بأقل قدر ممكن بحيث لا تتجاهل ريبو. تأكد من أنك تحقق في الجداول الفردية التي تتخذها بعد، وليس فقط كل شيء * .dbf، أو قد تكون في صدمة فظ عندما يحاول شخص آخر دفع العديد من جيجابايت من البيانات إلى ريبو لأن نسخة العمل لا قناع جميع الطاولات.