إصلاح المجموع الاختباري SVN

Question

أنا أستخدم مقطعًا فرعيًا في Flex Builder 3، وقد تلقيت مؤخرًا هذا الخطأ عند محاولة الالتزام:

svn: Checksum mismatch for '/Users/redacted/Documents/Flex Builder 3/path/to/my/file.mxml'; expected: 'f8cb275de72776657406154dd3c10348', actual: 'null'

لقد عملت حولها من خلال:

1. الالتزام بجميع الملفات الأخرى التي تم تغييرها، وحذف الملف المزعج.
2. نسخ محتويات ملف المشكلة إلى نافذة TextMate
3. حذف مشروعي في FlexBuilder/Eclipse
4. التحقق من مشروعي جديدًا من SVN
5. نسخ نص ملف المشكلة مرة أخرى من نافذة TextMate
6. ارتكاب التغييرات.

لقد نجح الأمر، لكن لا يسعني إلا أن أعتقد أن هناك طريقة أفضل.ما الذي يحدث فعليًا ليتسبب في ظهور خطأ svn:المجموع الاختباري، وما هو أفضل حل.

وربما الأهم من ذلك، هل هذا عرض لمشكلة أكبر؟

Answer 1

الملف الموجود في دليل .svn الذي يتتبع ما قمت بسحبه، ومتى، وما هي المراجعة، ومن أين، قد تعرض للتلف بطريقة ما، لهذا الملف المحدد.

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

ما لم يحدث المزيد فلن أجني الكثير منه.

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

لاحظ أن هذا قد يسبب مشاكل إذا كان لديك مشروع مزدحم حيث يتعين عليك عادةً دمج التغييرات.

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

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

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

Answer 2

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

@ أندرو هيدجز:وهذا ما يفسر أيضًا سبب قيام الحل الخاص بك بإصلاح هذه المشكلة.

Answer 3

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

بشكل عام، عدم تطابق المجموع الاختباري لـ SVN يعني أن الملف الذي لم يكن من المفترض أن يتم تعديله قد تم تغييره بطريقة ما.ماذا يعني ذالك؟

1. تلف القرص (HDD أو كبل IDE تالف)
2. ذاكرة الوصول العشوائي سيئة
3. رابط الشبكة سيئ
4. قام نوع ما من العمليات الخلفية بتغيير ملف خلف ظهرك (برامج ضارة)

كل هذه سيئة.

لكن, أعتقد أن مشكلتك مختلفة.انظر إلى رسالة الخطأ.لاحظ أنه كان يتوقع بعض تجزئات MD5، ولكنه بدلاً من ذلك استعاد القيمة "فارغة".إذا كانت هذه مشكلة تلف ملف بسيطة، أتوقع أنه سيكون لديك تجزئتان مختلفتان لـ MD5 للملف المتوقع/got.حقيقة أن لديك "فارغة" تشير إلى وجود خطأ آخر.

لدي نظريتان:

1. خطأ في SVN.
2. كان هناك شيء ما به قفل حصري على الملف، ولا يمكن أن يحدث MD5.

في الحالة رقم 1، حاول الترقية إلى أحدث إصدار من SVN.ربما يمكنك أيضًا نشر هذا على القائمة البريدية لـ svn-devel (http://svn.haxx.se)، حتى يتمكن المطورون من رؤيته.

في الحالة رقم 2، تحقق لمعرفة ما إذا كان هناك أي شيء يحتوي على الملف مقفلاً.يمكنك تنزيل نسخة من Process Explorer للتحقق.لاحظ أنك ربما تريد معرفة من لديه قفل على قاعدة النص file، وليس الملف الفعلي الذي كنت تحاول الالتزام به.

Answer 4

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

svn update

لإعادة إنشائه.

إذا كانت لديك تغييرات مباشرة في الدليل، فكما اقترحت أنت وlassevk بنفسك، يلزم اتباع نهج أكثر حذرًا.

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

Answer 5

اليوم فقط، تمكنت من التعافي من هذا الخطأ عن طريق فحص نسخة من الدليل التالف إلى /tmp واستبدال الملفات الموجودة في .svn/text-base بالملفات المختلطة فقط.لقد كتبت الإجراء بشيء من التفصيل هنا على مدونتي. سأكون مهتمًا بالسماع من مستخدمي SVN الأكثر خبرة ما هي مزايا وعيوب كل نهج.

Answer 6

يحاول:svn up --force file.c

نجح هذا بالنسبة لي دون الحاجة إلى القيام بأي شيء إضافي

Answer 7

لقد لاحظت الكثير من الحلول بدءًا من تصحيح ملف .svn/entries وحتى الخروج الجديد.

يمكن أن تكون طريقة جديدة (شكرًا لزملائي):

- go to work directory where recorder/expected checksum issue occured
- call "svn diff" and make sure that there isnt any local modifications
- cd ..
- remove trouble file's directory with "rm -rf"
- issue "svn up" command, svn client will restore new fresh files copies

Answer 8

مات، هناك طريقة أسهل مما وصفته - تعديل المجموع الاختباري في ملف .svn/entries.هنا وصف كامل:http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

Answer 9

الحل البديل الآخر، وربما الأكثر رعبًا، لتعارضات المجموع الاختباري الذي وجدته هو كما يلي:

تنبيه قضائي: تأكد من أن نسختك المحلية هي الإصدار الأكثر شهرة، وأن أي شخص آخر في مشروعك يعرف ما تفعله!(في حال لم يكن هذا واضحًا بالفعل).

إذا كنت تعلم أن نسختك المحلية من الملف هي "النسخة الجيدة"، فيمكنك حذف الملف مباشرةً من خادم SVN ثم فرض الالتزام بنسختك المحلية.

صيغة الحذف المباشر:

svn delete -m "deleting corrupted file XXXX" 
svn+ssh://username@svnserver/path/to/XXXX

حظ سعيد!

ج

Answer 10

كبديل للتحقق من نسخة جديدة (وهو ما كان عليّ أيضًا القيام به بعد تجربة جميع الخيارات الأخرى) وبدلاً من دمج جميع التغييرات التي قمت بحفظها مسبقًا مرة أخرى فيها، عملت الطريقة التالية بنفس الطريقة، ولكنها وفرت لي مبلغًا كبيرًا الوقت، وربما بعض الأخطاء:

1. تحقق من نسخة عمل جديدة
2. انسخ مجلد .svn من النسخة الجديدة إلى نسختك الفاسدة
3. هاهو

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

Answer 11

سيحدث هذا عند تلف المجلد .svn.حل:قم بإزالة المجلد بأكمله من الملف الذي يحتوي عليه وقم بالخروج من المجلد مرة أخرى.

Answer 12

في حالة حدوث هذه المشكلة، فإن الأجهزة الافتراضية الخاصة بالمطورين لدينا جميعها تعمل على إصلاح محطات العمل الخاصة بنا والتي تعمل بنظام التشغيل win32.بعض الخداع (S) أنشأت الملفات التي تحمل نفس الاسم (حالة مختلفة) على مربع *NIX جميع عمليات الخروج المفاجئة على ضربات Win32 ...لأن Win لا يعرف أي من الملفتين الذي يحمل نفس الاسم إلى MD5 مقابل ، كانت عمليات الخروج على *nix بخير ...ويتركنا لنحك رؤوسنا قليلاً

لقد تمكنت من تحديث الريبو في صندوق الفوز عن طريق نسخ مجلدات ".svn" من مربع *nix بنسخة عمل جيدة.لا يزال يتعين علينا معرفة ما إذا كان من الممكن تنظيف الريبو إلى النقطة التي يمكننا من خلالها إجراء عملية دفع كاملة مرة أخرى

Answer 13

طريقة اخرى سهلة ....

1. قم بتحديث مشروعك للحصول على أحدث إصدار
2. الخروج من نفس الإصدار في مجلد آخر
3. استبدل مجلد .svn من الخروج الجديد إلى نسخة العمل (لقد استبدلت ملفات .svn-base)

Answer 14

1. قم بفحص المجلد الوحيد الذي يحتوي على ملف به مشكلات من المستودع إلى موقع آخر.
2. تأكد .svn\text-base\<problematic file>.svn-base مطابق للواحد الذي تم سحبه.
3. تأكد من قسم الملفات الإشكالية (جميع أسطر القسم) في .svn\entries مطابق للواحد الذي تم سحبه.

Answer 15

لن تصدق هذا، لكنني أصلحت خطأي بالفعل عن طريق إزالة ملف <scm>...</scm> الموقف من ملف pom.xml المخالف الذي كنت أتمنى تسجيل الوصول إليه.لقد احتوى على عنوان URL لمستودع التخريب الذي تم تسجيل الوصول إليه (هذا هو الغرض من إعداد Maven!)، ولكن بطريقة ما أدى إلى إنشاء مجموع اختباري خاطئ للملف أثناء تسجيل الوصول.

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

Answer 16

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

1- الدليل المحذوف محليًا الذي تلف فيه الملف (WEB-INF):

 svn: Checksum mismatch for 'path-to-folder\WEB-INF\web.xml':
   expected:  d60cb051162e4a6790a3ea0c9ddfb434
     actual:  16885ded2cbc1adc250e4cbbc1427546

2- الدليل المنسوخ والملصق (WEB-INF) من صفحة الدفع الجديدة

3- هل تم رفع مستوى svn، والآن بدأ Eclipse/TortoiseSVN في إظهار التعارض في هذا الدليل

4- تم وضع علامة على الصراع على أنه تم حله

نجح هذا الأمر، وتمكنت من تحديث ملف web.xml التالف مسبقًا وارتكابه

Answer 17

في حالتي كان المبلغ مختلفا.كل ما فعلته هو:

1) قم بإجراء السحب لمجلد منفصل

2) استبدل بملف من هذا المجلد في دليل .svn بملف مشكلة مشروعي الذي قيل في رسالة خطأ عميل svn

3) ..الربح!

Answer 18

على الرغم من أن هذه مشكلة قديمة، إلا أنني اعتقدت أنني سأعطي سنتان أيضًا، حيث أنني تصارعت مع المشكلة لأكثر من ساعة.

الحلول المذكورة أعلاه إما لم تنجح بالنسبة لي، أو بدت معقدة للغاية.

كان الحل الخاص بي هو ببساطة إزالة جميع مجلدات svn من المشروع.

find . -name .svn -exec rm -rf {} \;

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

Answer 19

لقد واجهت هذه المشكلة على أوبونتو 14.04 وحلها باتباع الخطوات:

1. $ cd /var/www/myProject
2. ترقية $ svn
3. تحديث $svn

بعد هذه الخطوات يمكنني تنفيذ الملف دون أخطاء.

Answer 20

1. انتقل إلى المجلد الذي يسبب المشكلة
2. تنفيذ الأوامر svn update --set-depth empty
3. سيتم إفراغ هذا المجلد وإعادة المجلد الفارغ
4. المزامنة مع svn والتحديث.

هذا العمل بالنسبة لي.

Answer 21

وإليك كيفية إصلاح المشكلة - v بسيطة، ولكن وفقًا لـ jsh أعلاه، يجب التأكد من أن نسختك هي الأفضل.

ببساطة

1. عمل نسخة من كافة الملفات المشكلة، في نفس المجلد.
2. احذف القديم باستخدام svn rm
3. يقترف.
4. ثم أعد تسمية النسخ مرة أخرى إلى أسماء الملفات الأصلية.
5. ارتكاب مرة أخرى.

أظن أن هذا ربما يقتل جميع أنواع محفوظات المراجعة لهذا الملف، لذا فهي طريقة قبيحة جدًا للقيام بذلك ...