Composer: ذاكرة التخزين المؤقت للملحن تجعل حياة المطورين صعبة

هل لديك أي تفاصيل عن ذلك؟ أي جزء من ذاكرة التخزين المؤقت فشل ، وكيف؟ لم أواجه أي مشكلة مع ذاكرة التخزين المؤقت على حد علمي ، وأنا أعمل على win7 أيضًا.

أنا آسف للمسألة العامة جدًا ، فهي ليست مفيدة جدًا ، كما أعلم. كل ما في الأمر أننا لم نر أي نمط واضح حتى الآن. الشيء الوحيد الذي يحدث غالبًا هو أنه من الواضح أن هناك التزامات جديدة في dev-master ولكن الأشياء القديمة مأخوذة للتو من ذاكرة التخزين المؤقت. يقول الملحن: التثبيت من ذاكرة التخزين المؤقت ولكننا نعلم أن هذا ليس ما نريده. الطريقة الوحيدة للحصول على المعلومات الجديدة هي حذف ذاكرة التخزين المؤقت. سيكون من الأسهل بكثير أن يكون لديك طريقة composer clear-cache . ربما هناك شيء لا نفعله بشكل صحيح ... لا أعرف ماذا رغم ذلك.

أوه ، ولدينا نفس المشكلة على CentOS أيضًا ، بالمناسبة.

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

إذن أنت تقول أنه عند تحديث حزمة ، فإنها تُخرج أنها تُحدّث وتُجلب من ذاكرة التخزين المؤقت. هل يمكنك من فضلك كلما حصلت على هذا مرة أخرى ، قم بما يلي:

• اجمع المخرجات والصقها هنا (مهتمًا بشكل خاص بالإصدارات من / إلى الحزمة).
• تشغيل ونسخ إخراج هذا في cmd.exe: dir %LOCALAPPDATA%\Composer\files\<package name> لمعرفة الإصدارات / الملفات الموجودة في ذاكرة التخزين المؤقت بالضبط (إذا كان في CentOS: ls -l ~/.composer/cache/files/<package name> ).

حسنًا ، سأفعل ذلك.

أنا أعمل مع Markus وقد واجهت هذه المشكلة أكثر من مرة (في Windows 8 و CentOS) ، على سبيل المثال عندما أحتاج إلى إضافة بعض الملفات المفقودة إلى علامة git. قمت بما يلي:

• إضافة الملفات إلى الريبو المحلي
• أعاد إنشاء العلامة (إجبار الكتابة)
• دفع العلامة إلى جيثب
• أعاد بناء حزم الملحن / satis
• ركض php composer.phar update في مشروعي

حتى بعد حذف جميع التبعيات يدويًا قبل تشغيل php composer.phar update ، يقوم الملحن بتثبيت العلامة من ذاكرة التخزين المؤقت بدلاً من جلب العلامة المحدّثة بالملفات المضافة. بعد مسح ذاكرة التخزين المؤقت يدويًا ، يقوم الملحن بتثبيت العلامة المحدثة.

aimfeld لا يُقصد من علامات Git تغييرها. عندما تقوم بالكتابة فوق علامة ، يجب على كل شخص قام بالفعل بإحضار العلامة القديمة حذفها من استنساخها وإحضارها مرة أخرى ، وإلا فسيظلون يستخدمون العلامة القديمة.
لذلك يمكن أن تكون هذه مشكلة في ذاكرة التخزين المؤقت (التي تحتوي بالفعل على العلامة القديمة) ولكن حتى بدون ذاكرة التخزين المؤقت ، يمكن أن تكسر الأشياء إذا كنت قد جلبت بالفعل العلامة القديمة في مجلد البائع (مع تثبيت من المصدر) حيث ستقوم بتثبيت القديم علامة لاحقًا عند استخدام العلامة كمرجع git.

stof هذا صحيح في معظم الحالات ، لكننا هنا نتحدث عن إعادة شراء مرآة خاصة لمكتبة تابعة لجهة خارجية تحتاج إلى الحفاظ على علامتها ولكنها حصلت على بعض الإصلاحات.

markushausammann حتى بالنسبة

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

يبدو لي أن إعادة استخدام نفس رقم الإصدار لإصدار ولكن بمحتوى مختلف.

markushausammannaimfeld بالفعل إعادة وضع العلامات هي المشكلة. هذه حقا ممارسة سيئة. إذا تم كسر 1.0.0 ، يمكنك دفع الإصلاحات وإصدار 1.0.0.1 أو 1.0.0p1 وكلاهما مقبول من قبل الملحن كإصدارات تصحيح ثانوية / إصلاح عاجل.

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

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

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

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

أنت بناء جدا :)

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

لذلك ربما يجب على الملحن أن يتحقق مرة أخرى من المجموع الاختباري لذاكرة التخزين المؤقت مقابل packagist للحصول على تحديثات إجبارية للعلامات والحزم.

واجهت مشكلة مماثلة عند نقل الحزمة من packagist إلى خادم satis. بقيت العلامة كما هي كما لم تتغير الريبو ، فشل المجموع الاختباري md5 (لست متأكدًا مما تم تضمينه فيه). هل يمكن أن يختلف المجموع الاختباري Packagist / satis لنفس الحزمة أو أني أفقد شيئًا ما؟

ربما يجب مسح ذاكرة التخزين المؤقت لـ pacakge إذا فشل المجموع الاختباري؟

tomaszdurka أعتقد أن ساتيس يعيد حزم الأشياء.
هل المجموع الاختباري محسوب للملفات قبل أو بعد الحزم؟
ربما تتأثر عملية إعادة التغليف أيضًا بخلل المحاكاة هذا .gitignore .

هذه ملفات مضغوطة لنفس الريبو ، نفس المرجع / العلامة:

• MD5 (/tmp/satis.zip) = 0b719b5685591286446476dbc6789698
• MD5 (/tmp/packagist.zip) = 82aa4716f2523a9039507d01bbc709a2

في الواقع:
يبدو أن packagist يلف الحزمة في دليل ( <project-name>-<version> ) ، بينما satis لا يفعل ذلك. من المحتمل أن تكون هذه مشكلة أكبر لمشروع https://github.com/composer/satis .

نحن نواجه كلتا القضيتين هنا

• SHASUM مختلف ، على 2 ساتيس (تشترك في نفس التكوين)
• مخبأ يزعجنا ، عند التحديث أو التثبيت عبر الملحن.

Seldaek هل تلقيت إشعارات بهذا الشأن؟

أهلا،

اعتدت على وجود أخطاء في المجموع الاختباري أثناء استخدام Satis ؛ لم أعد أفعل ذلك لأنني عطلت ذاكرة التخزين المؤقت على كلا الجانبين:

"config:{
    "cache-files-ttl": 0
}

منذ بضعة أسابيع ، أواجه أن ملفات ZIP المخزنة مؤقتًا لها مجاميع اختبارية مختلفة عن الملفات الأصلية الموجودة على satis.

ثم يقول الملحن شيئًا مثل:

 - Installing easybook/geshi (1.0.8.11)
    Loading from cache

  [UnexpectedValueException]                                                                                                                                                  
  The checksum verification of the file failed (downloaded from http://satis.cargomedia.ch/dist/dist/easybook-geshi-2582e8134c8af41d7f367e421ee0b8b111e89f36-zip-f3a77f.zip)  

يختلف الملف المخزن مؤقتًا بالفعل عن الملف الموجود على satis:

$ md5sum ~/.composer/cache/files/easybook/geshi/1.0.8.11-1.0.8.11.zip 
f26396c9ca9f2e89e3c99edfa4a5401e  /root/.composer/cache/files/easybook/geshi/1.0.8.11-1.0.8.11.zip
$ curl -s http://satis.cargomedia.ch/dist/dist/easybook-geshi-2582e8134c8af41d7f367e421ee0b8b111e89f36-zip-f3a77f.zip | md5sum
f99a691ad94190be33f6321cb769c8e7  -

إذا قمت بفك ضغط كلا من ملفات ZIP فهما متطابقان ( diff -r ) ، لكن ملفات ZIP نفسها مختلفة:

$ diff easybook-geshi-2582e8134c8af41d7f367e421ee0b8b111e89f36-zip-f3a77f.zip 1.0.8.11-1.0.8.11.zip 
Binary files easybook-geshi-2582e8134c8af41d7f367e421ee0b8b111e89f36-zip-f3a77f.zip and 1.0.8.11-1.0.8.11.zip differ

مع الاختلاف يبدو وكأنه بعض الترميز المختلفة (؟):

$ diff -a easybook-geshi-2582e8134c8af41d7f367e421ee0b8b111e89f36-zip-f3a77f.zip 1.0.8.11-1.0.8.11.zip 
1c1
composer.jsonnuW+A??{
---
composer.jsonnuW+A??{
24c24
< }PKBC??n??    README.mdnuW+A??# GeSHi - Generic Syntax Highlighter #
---
> }PKy??B??n??  README.mdnuW+A??# GeSHi - Generic Syntax Highlighter #
[.....]

أي أفكار يمكن أن يكون السبب أو كيفية إجراء مزيد من التصحيح؟

إنها تشبه مشكلة Satis ، المتعلقة بحقيقة أن خوارزمية ZIP ليست حتمية. لا يغير Composer أي شيء إلى ملف ZIP الذي تم تنزيله من خادم Satis ؛ تنشأ المشكلة فقط إذا:

• يقوم Composer بتنزيل حزمة من Satis ، ويضعها في ذاكرة التخزين المؤقت ويكتب مبلغ الاختيار الخاص بها في composer.lock
• يقوم خادم Satis بإنشاء ملف ZIP للحزمة نفسها مرة أخرى ، على الرغم من أن الحزمة نفسها ورقم إصدارها لم يتغير. يختلف ملف ZIP الجديد هذا عن الملف الأصلي ، رغم ذلك - هذا هو الخطأ الفعلي في رأيي.
• يتم مسح ذاكرة التخزين المؤقت لـ Composer أو يتم تنفيذ Composer على جهاز آخر حيث لم يتم تنزيل الحزمة بعد
• composer install بتنزيل ملف ZIP الجديد من خادم Satis

فشل التحقق من صحة مجموع التحقق بعد ذلك لأن مبلغ الشيك الموجود في composer.lock يتوافق مع ملف ZIP الأصلي ، بينما يتوافق مجموع التحقق من الملف الذي تم تنزيله مع ملف ZIP الجديد الذي أنشأه Satis في الوقت نفسه.

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

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

find . -type f -exec md5sum {} + | awk '{print $1}' | md5sum

(مستوحى من هذه الإجابة على StackOverflow)

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

لقد ألقيت نظرة على Composer\Satis\Command\BuildCommand::dumpDownloads() ، ويبدو أن Satis لن يقوم بالكتابة فوق أرشيفات الحزم الحالية عندما يتم إنشاء الخادم مرة أخرى ، نظرًا لأننا نستخدم:

$archiveManager->setOverwriteFiles(false);

لذا فإن المشكلة ستنشأ فقط إذا قمت بحذف أرشيفات الحزمة من خادم Satis يدويًا ، ثم أعدت إنشائها؟ هل يمكن لأي شخص أن يؤكد أو يدحض هذه النظرية؟

Seldaek ماذا عن اقتراحي؟ هل سيكون من الجيد إضافة مبلغ الشيك للأرشيفات _inflated_ ، ربما عن طريق إدخال جديد shasum-inflated في composer.lock ؟ يمكننا بعد ذلك استخدامه كبديل في حالة عدم تطابق مجموع التحقق للأرشيف نفسه.

يبدو أن المشكلة بالنسبة لنا كانت أقدم composer.lock الذي استخدم أسماء ملفات من satis مثل ruflin-elastica-v0.19.8.0-v0.19.8.0-93e4c9.zip بدلاً من ما يبدو الآن ruflin-elastica-34a7e62a257febd5295efeacfa0209712e0ceb65-zip-f92c51.zip .
يحتوي هذان الملفان على نفس إصدار المكتبة ، وبالتالي تمت معاملتهما على أنهما نفس الملف بواسطة ذاكرة التخزين المؤقت للملحن. نظرًا لأنها كانت ملفات ZIP مختلفة على satis ، اختلفت shasums.
يستخدم satis الآن بشكل صحيح اسم الملف الأخير فقط ، لذا فإن إعادة إنشاء composer.lock يجب أن يحل هذه المشاكل.

لذلك يبدو أن هناك مشكلتين في متناول اليد حقًا:

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

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

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

اي فكرة افضل؟

لقد اضطررت للتو إلى إعادة إنشاء جميع ذاكرات التخزين المؤقت للحزم وإعادة إنشاء composer.lock s في جميع المشاريع. السبب في اعتقادي كان تغييرًا إما في satis أو الملحن (أن أسماء الملفات تحتوي الآن على shasums بدلاً من أرقام الإصدارات).

لمنع ذلك ، من المحتمل أن يكون الأكثر أمانًا هو حساب shasum من محتويات ZIP.
الجوانب السلبية هي أن أدائك في الكتابة أبطأ ، والحاجة إلى إعادة إنشاء الكثير من composer.lock s - لذا لست متأكدًا ..

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

ماذا عن تضخيم أرشيفات الحزم في الذاكرة لحساب مبلغ الشيك المتضخم الذي سنخزنه في composer.lock ؟

لن يعمل ذلك على الأنظمة التي لا تحتوي على امتداد مضغوط ، وحتى على تلك الأنظمة
لا يزال الأمر أبطأ بكثير من مجرد تجزئة الأرشيف بالكامل.

هذا صحيح ... فيما يتعلق بالأداء ، في الحالة "العادية" ، لن يتأثر composer install ، لأننا سنحسب فقط المجموع الاختباري المتضخم في composer update للتخزين إلى composer.lock . سنحسبه فقط على composer install أيضًا إذا لم يتطابق المجموع الاختباري المفرغ - كإجراء احتياطي. ويمكننا تحديث المجموع الاختباري المفرغ في composer.lock في هذه الحالة ، بحيث يتطابق في المرة القادمة. (آمل فقط ألا يؤدي القيام بذلك إلى فتح مشكلة أمنية جديدة - علينا توخي الحذر ...)

نظرًا لأن هذه ليست سوى ميزة ملائمة ، يمكننا أيضًا جعلها اختيارية ، على ما أعتقد؟

الحل الحالي هو export COMPOSER_CACHE_DIR=/dev/null لتجنب الانقطاع في عملية التثبيت التلقائي ، ولكن جميع الملفات متوفرة على الشبكة المحلية ، وبالتالي فإن إعادة التنزيل الإضافية ليست مشكلة.

أواجه مشكلة كون خوارزمية ZIP غير حتمية بهذه الطريقة: أستخدم خادم Linux في الشركة التي تبني مستودعًا باستخدام Satis. في محطة العمل الخاصة بي في المنزل ، أرغب في توفير مستودع Satis ثانٍ من نفس الحزم ، والذي يفضل أن يستخدمه تثبيت Composer الخاص بي لأنه أسرع للوصول محليًا منه عبر الإنترنت.

تكمن المشكلة في أن محطة العمل المحلية الخاصة بي تعمل بنظام التشغيل Windows 7 وأن ملفات Zips التي تم حذفها من خلال تثبيت Satis تختلف عن تلك التي تم إنشاؤها على خادم Linux. يؤدي هذا إلى مشاكل في المجموع الاختباري عندما يكون ملف Zip من أحد الخوادم في ذاكرة التخزين المؤقت ويتوقع Composer المجموع الاختباري من الخادم الآخر.

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

1. تأكد من أن تجزئات الحزمة لا تعتمد على أرشيف Zip النهائي ولكن على تمثيل محدد للبيانات في شكل غير مضغوط.
2. تخزين الحزم في ذاكرة التخزين المؤقت ليس فقط بالاسم ، ولكن أيضًا حسب الخادم الأصلي. قد يكون هذا حلاً مؤقتًا لحالات عدم تناسق خوارزمية ZIP عبر الخادم.

واجهت اليوم تباينًا مختلفًا قليلاً في المشكلة حيث يحسب Composer التجزئة على النسخة المضغوطة بدلاً من البيانات الأصلية. هذه المرة لم يكن مسح ذاكرة التخزين المؤقت كافيًا لأن المشروع المقابل كان يحتوي على ملف composer.lock تم إيداعه ولذا أصر Composer على الحصول على أرشيف به تجزئة لم يعد متاحًا لأن النسخة المضغوطة من الحزمة قد تغيرت في غضون ذلك بينما ظلت البيانات الأصلية دون تغيير. تم التحقق من ذلك من خلال مقارنة النتائج في الدلائل vendor من اثنتين من التثبيتات بعد فرض التثبيت عن طريق إزالة ملف composer.lock . تم تغيير الإدخال shasum لحزمتين فقط ، وظل كل شيء على حاله.

مضيفا cache ttl 0 insta عملت لي ، شكرا.

+1

تحرير بعد تعليق markushausammann أدناه:
هذا يسبب لي مشكلة مرة واحدة على الأقل في اليوم. لا أريد أن أضطر إلى ضبط cache-ttl في كل من مشاريعي composer.json's.

يتم تشغيل ساتيس الخاص بي كل 5 دقائق ببنية كاملة ، وبعد كل دفعة على مشاريع معينة.

: +1:

أنا حقًا لست متأكدًا مما ترفضه يا رفاق. لقد قيلت الكثير من الأشياء في هذه المسألة بحيث يمكن أن تكون أي شيء من "نعم ، هذا يجعل حياتي صعبة للغاية" إلى "التخزين المؤقت لأعمال ttl 0". إذا أجريت +1 أو إبهامًا لأعلى ، فيرجى توضيح ما تدعمه.

حسنًا ، نعم ، هذا بيتا ، و "cache-files-ttl": 0 "يصلح" الآن ، لكن هذا ليس هو الأمثل على الإطلاق. سيكون من الأفضل استبدال ذاكرة التخزين المؤقت السابقة عندما يختلف المجموع الاختباري ، ولا يستطيع الملحن معرفة أيهما هو الأفضل من ذاكرة التخزين المؤقت أو الأرشيف البعيد على أي حال ، لذلك دعنا نفترض أن التخزين المؤقت الجديد على ما يرام ونستخدمه ، وهذا من شأنه تجنب الانكسار على عمليات النشر. هذه ذاكرة تخزين مؤقت ، وليست فحصًا لاتساق المستودع ، ومن المفترض أن تكون شفافة ولا ينبغي لأحد أن يهتم بها.

@ peikk0 : +1 عند استبدال الملف المخزن مؤقتًا على فرق المجموع الاختباري.

سيكون هذا إلى حد بعيد الحل الأبسط للإزعاج الحالي.
تعيين "cache-files-ttl": 0 ليس حلاً ، هذا يعني التخلي تمامًا عن فكرة التخزين المؤقت.

لقد أصلحت ما يمكن إصلاحه الآن ، على سبيل المثال ، لن يتم استخدام ذاكرات التخزين المؤقت "التالفة" التي لا تتطابق مع sha-1 بعد الآن وسيتم فرض إعادة التنزيل بدلاً من ذلك. تم نقل باقي العدد إلى 2540 #.

لا تزال ذاكرة التخزين المؤقت معطلة عند استخدام إصدار @dev من حزم Github المستضافة:

Composer version 1.2.1 2016-09-12 11:27:19

$ composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing level-2/transphporm (dev-master 2110304)
    Cloning 2110304c512958797508ea08e0d78c4336494b41 from cache

Writing lock file
Generating autoload files
master

$ git log origin
commit 0ada294c2ecd1698782985a23f3c90c142fab7b4 (refs/remotes/origin/master, refs/remotes/origin/HEAD, refs/remotes/composer/master)
Author: Tom Butler <[email protected]>
Date:   Tue Sep 13 15:51:36 2016 +0100

    #124 - fixed bug with empty value

commit 2110304c512958797508ea08e0d78c4336494b41 (HEAD -> refs/heads/master)
Author: Richard <[email protected]>
Date:   Fri Aug 12 08:17:02 2016 -0400

    Removed unused class properties

لاحظ كيف سحب Composer الإصدار القديم 2110304 من 12 أغسطس من ذاكرة التخزين المؤقت ، بدلاً من الحصول على الإصدار 0ada294c من Github.

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