SVN - كيف يمكنني اعتراض الملفات وتعديلها أو إضافتها عند الالتزام المسبق؟

Question

أولا، لست متأكدا من أن هذا ممكن، ولكن أريد أن أعرف كيف يمكن القيام بذلك، وإذا لم يكن الأمر كذلك فلماذا لا؟

أرغب في إنشاء تطبيق C# يتم تشغيله في الوقت المناسب أثناء عملية الالتزام لمستودع التخريب (الالتزام المسبق على ما أعتقد) والذي سيضيف بعد ذلك ملفًا آخر ليتم الالتزام به.

على سبيل المثال، أقوم بإجراء تغييرات على Program.cs، وMain.cs، ولكن لا معلومات التجميع.cs.أريد أن أكون قادرًا على فرض تغيير على AssemblyInfo.cs أو أي ملف في هذا الشأن.

لقد قمت بكتابة تطبيق وحدة تحكم باستخدام SharpSVN الذي تم تشغيله بعد الالتزام، والذي قام بعد ذلك باستبدال ملف، ولكن هذا تسبب في زيادة في رقم المراجعة.ومن الواضح أن هذا ليس مثاليا.

بعد ذلك وجدت SvnLookClient داخل SharpSVN الذي يعمل بنظام الالتزام المسبق وبدأت في كتابة شيء ما، لكنني وصلت إلى طريق مسدود عندما أدركت أن CopyFromPath لا يعني ما كنت أتوقعه:

    using (SvnLookClient client = new SvnLookClient())
    {
        SvnLookOrigin o = new SvnLookOrigin(@"\\server\repository");
        SvnChangedArgs changedArgs = new SvnChangedArgs();
        Collection<SvnChangedEventArgs> changeList;
        client.GetChanged(o, changedArgs, out changeList);
    }

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

Answer 1

يجب عدم تعديل المعاملة أثناء البرنامج النصي للربط.يمكنك إما رفض الالتزام برسالة (سيتم إرسال stderr إلى العميل)، أو قم بذلك في التزام منفصل في مرحلة ما بعد الالتزام.

تحرير] أريد أن أوضح لماذا يعد تعديل المعاملات فكرة سيئة (من الناحية الفنية svn):

العميل لا يعرف شيئا عن ذلك.

باستثناء "موافق" و"فشل" ومخرجات stderr، لا توجد قناة خلفية من الخادم إلى العميل أثناء الالتزام.

عندما ينفذ العميل تغييراته، ويتم الإبلاغ عن نجاح الالتزام، فإنه يحدد حالة الملف والمجلد المحلي الخاص به لتكون متزامنة مع إصدار المستودع [xyz].عندما تقوم بتغيير شيء ما لاحقًا، على سبيل المثال، إضافة الملف محليًا، فإنه يريد تنفيذ هذه التغييرات، ولكن بعد ذلك...حسنًا، يمكنك محاولة معرفة ما يحدث، أتوقع شيئًا ما مثل "خطأ في المجموع الاختباري" أو "تمت إضافة الملف بالفعل".اعتمادًا على نوع التغييرات، ربما لن تكون لديك فرصة أفضل للحصول على مرحاض يعمل بشكل أفضل من حذف المجلد وإجراء فحص جديد للجزء التالف.

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

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

يمكن أيضًا أن تكون رسالة الخطأ من خادم svn، أو البريد الآلي بعد عمليات البناء المعطلة أو اختبارات الوحدة، أو النتائج من أداة تحليل كود المصدر الثابتة، وما إلى ذلك، بمثابة أداة تعليمية جيدة.

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

وأنا الآن أخمن فقط ما تريد محاولة تحقيقه:يجب أن تكون شجرة المصدر من جانب الخادم "وظيفية" دائمًا.إذن المشكلة هي أنه حتى مع الإصلاح التلقائي للملفات، واختبار الوحدة المسبق، والتحقق من النمط، وما إلى ذلك، لا يزال يتعين عليك في النهاية التحقق مما إذا كان البرنامج يعمل بالفعل، عن طريق اختبار النظام القديم.لذلك في الأساس، أنت لا تكسب أي شيء حقًا.

يمكن للتكنولوجيا أن تدعم العمليات، والأدوات المدروسة تدعمها بشكل جيد لدرجة أن العمليات التالية تساعد المطورين في الواقع على توفير الوقت وجعل سير العمل الخاص بهم أكثر بساطة.لكن التكنولوجيا عادة لا تستطيع أن تحل محل العمليات، ولا يمكنها أن تحل محل الذكاء البشري (على الأقل في الوقت الحالي).[/يحرر]