git-import الأصلية الموزعة مع ClickHouse.
توفّر البيانات الناتجة ملف tsv لكل جدول من الجداول التالية:
commits- عمليات commit مع الإحصاءات.file_changes- الملفات التي تغيّرت في كل commit، مع معلومات عن التغيير والإحصاءات.line_changes- كل سطر تغيّر في كل ملف تغيّر في كل commit، مع معلومات كاملة عن السطر ومعلومات عن آخر تغيير سابق لهذا السطر.
commits- 7.8M - 266,051 صفًاfile_changes- 53M - 266,051 صفًاline_changes- 2.7G - 7,535,157 صفًا
توليد البيانات
- Linux -
~/clickhouse git-import- 160 دقيقة
تنزيل البيانات وإدراجها
- ClickHouse (8 نوفمبر 2022)
- https://datasets-documentation.s3.amazonaws.com/github/commits/clickhouse/commits.tsv.xz - 2.5 MB
- https://datasets-documentation.s3.amazonaws.com/github/commits/clickhouse/file_changes.tsv.xz - 4.5MB
- https://datasets-documentation.s3.amazonaws.com/github/commits/clickhouse/line_changes.tsv.xz - 127.4 MB
- Linux (8 نوفمبر 2022)
INSERT INTO SELECT ودالة s3. على سبيل المثال، نُدرِج أدناه ملفات ClickHouse في الجداول المقابلة لها:
commits
الاستعلامات
git_clickhouse. ونوفر رابطًا إلى هذه البيئة لجميع الاستعلامات، مع تكييف اسم قاعدة البيانات حسب الحاجة. يُرجى ملاحظة أن نتائج play قد تختلف عن تلك المعروضة هنا بسبب اختلاف وقت جمع البيانات.
سجلّ ملف واحد
StorageReplicatedMergeTree.cpp. ونظرًا إلى أن الأحدث غالبًا ما تكون أكثر إثارة للاهتمام، فإننا نفرزها بحيث تظهر أحدث الرسائل أولًا.
تشغيل
العثور على الملفات الحالية النشطة
dbms وlibs وtests/testflows/ أثناء إعادة تسميتها. لذلك نستبعد هذه أيضًا.
تشغيل
old_path للحصول على قائمة بالملفات المحذوفة نتيجة إعادة التسمية. ثم نضمّ هذه القائمة إلى آخر عملية لكل path. وأخيرًا، نرشّح هذه القائمة للاحتفاظ فقط بالعناصر التي لا يكون فيها الحدث الأخير Delete.
تشغيل
--skip-paths 'generated\.cpp|^(contrib|docs?|website|libs/(libcityhash|liblz4|libdivide|libvectorclass|libdouble-conversion|libcpuid|libzstd|libfarmhash|libmetrohash|libpoco|libwidechar_width))/'
يُظهر تطبيق هذا النمط على git list-files العدد 18155.
- قد تحدث إعادة التسمية بالتزامن مع تعديلات أخرى على الملف. وتُسجَّل هذه كأحداث منفصلة في file_changes ولكن في الوقت نفسه. ولا تملك الدالة
argMaxأي طريقة للتمييز بينها، لذا تختار أول قيمة. كما أن الترتيب الطبيعي لعمليات الإدراج (وهو الوسيلة الوحيدة لمعرفة الترتيب الصحيح) لا يُحفَظ عبر عمليةunion، لذلك قد تُختار أحداث التعديل. على سبيل المثال، في الأسفل خضع الملفsrc/Functions/geometryFromColumn.hلعدة تعديلات قبل إعادة تسميته إلىsrc/Functions/geometryConverters.h. وقد يختار حلّنا الحالي حدث Modify على أنه أحدث تغيير، مما يؤدي إلى الإبقاء علىsrc/Functions/geometryFromColumn.h.
- سجلّ تاريخ commit معطّل - أحداث الحذف مفقودة. لم يُحدَّد المصدر والسبب بعد.
عرض الملفات الأكثر تعديلًا
في أي يوم من أيام الأسبوع تُجرى عمليات commit عادةً؟
سجل الدليل الفرعي/الملف - عدد الأسطر وعمليات commit والمساهمين بمرور الوقت
toStartOfWeek — عدِّل ذلك حسب الحاجة.
تشغيل
أقدم أسطر الشيفرة في المستودع
الملفات ذات السجلّ الأطول
توزيع المساهمين بين التوثيق والشفرة البرمجية على مدار الشهر
docs/ بسبب السجل شديد الفوضى للالتزامات (commit). لذلك، فإن نتائج هذا الاستعلام غير دقيقة.
هل نكتب مزيدًا من التوثيق في أوقات معيّنة من الشهر، مثلًا قرب تواريخ الإصدار؟ يمكننا استخدام الدالة countIf لحساب نسبة بسيطة، ثم عرض النتيجة بصريًا باستخدام الدالة bar.
جرّب
bar على تصوّر هذه التوزيعات:
جرّب
sign = -1 إلى حذف شيفرة. نستبعد علامات الترقيم وإدراج الأسطر الفارغة.
جرّب
LIMIT BY إلى 3 للحصول على أبرز 3 أشخاص يزيلون الشيفرة لكل مؤلف، مما يعزّز التنوع في التصور المرئي.
من الواضح أن Alexey يميل إلى إزالة شيفرة الآخرين. لنستبعده للحصول على عرض أكثر توازنًا لعمليات إزالة الشيفرة.
من هو المساهم ذو أعلى نسبة مئوية في كل يوم من أيام الأسبوع؟
توزيع أعمار الشيفرة في المستودع
سرد الملفات التي أُعيدت كتابتها أكبر عدد من المرات؟
path وcommit_hash، مع إرجاع عدد الأسطر المضافة والمحذوفة. وباستخدام window function، نقدّر الحجم الإجمالي للملف في أي لحظة زمنية عبر إجراء مجموع تراكمي، وتقدير أثر أي تغيير في حجم الملف على أنه lines added - lines removed. واستنادًا إلى هذا المقياس، يمكننا حساب النسبة المئوية من الملف التي أُضيفت أو أُزيلت في كل تغيير. وأخيرًا، نحصي عدد تغييرات الملفات التي تُعدّ إعادة كتابة لكل ملف، أي (percent_add >= 0.5) AND (percent_delete >= 0.5) AND current_size > 50. لاحظ أننا نشترط أن يزيد حجم الملفات على 50 سطرًا لتجنب احتساب المساهمات المبكرة في الملف على أنها إعادة كتابة. كما يجنّب ذلك الانحياز نحو الملفات الصغيرة جدًا، التي قد تكون أكثر عرضة لإعادة الكتابة.
تشغيل
في أي يوم من أيام الأسبوع تكون احتمالية بقاء الشيفرة في المستودع هي الأعلى؟
الملفات المرتبة حسب متوسط عمر الشيفرة
من يميل إلى كتابة المزيد من الاختبارات / شيفرة CPP / التعليقات؟
tests، ثم يحسب نسبتها إلى إجمالي المساهمات.
نقصر هنا الاستعلام على المستخدمين الذين لديهم أكثر من 20 تغييرًا، للتركيز على المساهمين المنتظمين وتجنب الانحياز إلى المساهمات العابرة.
play
ما متوسط المدة قبل إعادة كتابة الشيفرة، وما الوسيط (نصف عمر تآكل الشيفرة)؟
ما أسوأ وقت لكتابة الشيفرة من حيث ارتفاع احتمال إعادة كتابتها؟
consecutive_day.
بعد ذلك، تحسب array functions أطول sequence من القيم 1 المتتالية لكل مؤلف. أولًا، تُستخدم الدالة groupArray لتجميع جميع قيم consecutive_day الخاصة بالمؤلف. ثم يُقسَّم هذا Array من القيم 1 و0 عند القيم 0 إلى Arrays فرعية. وأخيرًا، نحسب أطول Array فرعي.
تشغيل
سجل الالتزامات لكل سطر في ملف
path على المسار الجديد للملف، بينما يمثّل old_path الموقع السابق، على سبيل المثال.
تشغيل
file_path_history('src/Storages/StorageReplicatedMergeTree.cpp')، نتتبّع سجل إعادة التسمية بصورة تكرارية، بحيث يستدعي كل استدعاء للدالة المستوى التالي باستخدام old_path. وتُدمَج النتائج باستخدام arrayConcat.
على سبيل المثال،
path.
أسئلة عالقة
Git blame
arrayFold أو arrayReduce، ما يتيح الاحتفاظ بالحالة في كل تكرار.
وقد يبدو الحل التقريبي التالي، وهو كافٍ لتحليل عام عالي المستوى، كما يلي: