كما تمت مناقشته في # 940 ، أعتقد أننا سنحتاج إلى توحيد تخطيط المستودع بما تستخدمه الخلفيات المحلية / sftp. أود البدء في التحرك نحو هذا الاتجاه. الأساس المنطقي هو أن وجود تخطيط واحد فقط بغض النظر عن الواجهة الخلفية يسمح بسهولة بنقل البيانات حولها والوصول إلى الريبو ، لذلك "يعمل فقط". يعد التخطيط المحلي بمثابة حل وسط جيد بين عدد الأدلة الفرعية وعدد الملفات. من المحتمل أن نتخلى عن قيود 16 ميغا بايت لكل ملف حزمة في المستقبل القريب ، وهذا من شأنه أن يكون أفضل بكثير للمستودعات الكبيرة جدًا.
قائمة المهام هي تقريبًا كما يلي:
design.rst
migrate
(أو شيء مشابه) لتحويل s3 repo إلى التنسيق الافتراضييمكن بالفعل للخلفيات المحلية / sftp الكشف التلقائي عن التخطيط واستخدامه فقط.
(يمكنني إضافة المزيد من عناصر القائمة).
في الوقت الحالي ، أود الاحتفاظ ببروتوكول REST والخادم كما هو ، تأكد zcalusic في تطبيق الخادم من أن تنسيق القرص هو التخطيط المحلي.
لقد قمت للتو بدمج # 966 الذي يضيف دعمًا للتخطيط الافتراضي إلى الواجهة الخلفية s3. سيتم تناول القضايا الأخرى في العلاقات العامة الجديدة. لا يزال التخطيط الافتراضي للواجهة الخلفية s3 هو s3legacy
.
منتهي. default
هو الآن التخطيط الافتراضي للواجهة الخلفية s3 ، وهناك أمر ترحيل.
هل سيتلقى المستخدمون رسالة لطيفة عند وصولهم إلى مستودع S3 قديم يطلب منهم تشغيل الترحيل؟ أم أنها كلها تحت السطح ولن يعرفوا أبدًا حتى تقوم بإسقاط دعم s3_legacy؟
حسنًا ، لم أخطط لذلك بمثل هذه التفاصيل. سنذكر ذلك بالتأكيد في سجل التغيير وعندما نتخلص تدريجياً من s3legacy في عدد قليل من الإصدارات ، فربما نعرض تحذيرات. يجب أن تفعل ذلك. أيضًا ، وثائق الأمر migrate
لم تنته بعد.
التعليق الأكثر فائدة
لقد قمت للتو بدمج # 966 الذي يضيف دعمًا للتخطيط الافتراضي إلى الواجهة الخلفية s3. سيتم تناول القضايا الأخرى في العلاقات العامة الجديدة. لا يزال التخطيط الافتراضي للواجهة الخلفية s3 هو
s3legacy
.