التعامل مع توسيع الكلمات الرئيسية SVN باستخدام git-svn

Question

لقد سألت مؤخرا عن توسيع الكلمات الرئيسية في Git وأنا على استعداد لقبول التصميم لعدم دعم هذه الفكرة حقًا في Git.

للأفضل أو الأسوأ، يتطلب المشروع الذي أعمل عليه حاليًا توسيع الكلمات الرئيسية لـ SVN مثل هذا:

svn propset svn:keywords "Id" expl3.dtx

للحفاظ على هذه السلسلة محدثة:

$Id: expl3.dtx 803 2008-09-11 14:01:58Z will $

لكنني أرغب تمامًا في استخدام Git للتحكم في الإصدار الخاص بي.لسوء الحظ، لا يدعم git-svn هذا، وفقًا للمستندات:

"نحن نتجاهل كافة خصائص SVN باستثناء svn: القابل للتنفيذ"

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

Answer 1

ما الذي يحدث هنا:تم تحسين Git للتبديل بين الفروع في أسرع وقت ممكن.بخاصة، git checkout تم تصميمه بحيث لا يمس أي ملفات متطابقة في كلا الفرعين.

ولسوء الحظ، فإن استبدال الكلمات الرئيسية لـ RCS يكسر هذا.على سبيل المثال، باستخدام $Date$ قد يحتاج git checkout لمس كل ملف في الشجرة عند تبديل الفروع.بالنسبة لمستودع بحجم نواة Linux، فإن هذا من شأنه أن يؤدي إلى توقف كل شيء بشكل صارخ.

بشكل عام، أفضل رهان لك هو وضع علامة على إصدار واحد على الأقل:

$ git tag v0.5.whatever

... ثم اتصل بالأمر التالي من ملف Makefile الخاص بك:

$ git describe --tags
v0.5.15.1-6-g61cde1d

هنا، يخبرني git أنني أعمل على إصدار مجهول الإصدار 6 يلتزم بما يتجاوز الإصدار v0.5.15.1، مع تجزئة SHA1 تبدأ بـ g61cde1d.إذا قمت بلصق إخراج هذا الأمر في ملف *.h الملف في مكان ما، فأنت في العمل، ولن تواجه أي مشكلة في ربط البرنامج الذي تم إصداره مرة أخرى بكود المصدر.هذه هي الطريقة المفضلة لفعل الأشياء.

إذا لم يكن بإمكانك تجنب استخدام الكلمات الأساسية لـ RCS، فقد ترغب في البدء بهذا شرح لارس جمللي.أساسًا، $Id$ من السهل جدًا، وأنت إذا كنت تستخدم git archive, ، تستطيع ايضا استخذام $Format$.

ولكن، إذا لم تتمكن مطلقًا من تجنب الكلمات الرئيسية لـ RCS، فيجب أن تبدأ بما يلي:

git config filter.rcs-keyword.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
git config filter.rcs-keyword.smudge 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date: `date`\\\$/"'

echo '$Date$' > test.html
echo 'test.html filter=rcs-keyword' >> .gitattributes
git add test.html .gitattributes
git commit -m "Experimental RCS keyword support for git"

rm test.html
git checkout test.html
cat test.html

على نظامي، أحصل على:

$Date: Tue Sep 16 10:15:02 EDT 2008$

إذا كنت تواجه مشكلة في هروب القذيفة في smudge و clean لكي تعمل الأوامر، ما عليك سوى كتابة نصوص Perl النصية الخاصة بك لتوسيع وإزالة الكلمات الرئيسية لـ RCS، على التوالي، واستخدام تلك البرامج النصية كمرشح.

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

Answer 2

لسوء الحظ ، فإن استبدال الكلمات الرئيسية RCS يكسر هذا.على سبيل المثال ، سيتطلب استخدام $ date $ $ git headout لمس كل ملف في الشجرة عند تبديل الفروع.

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

   $Date$ The  date  and  time the revision was checked in.  With -zzone a
          numeric time zone offset is appended;  otherwise,  the  date  is
          UTC.

وهذا يعني أيضًا أن الإجابة المقترحة أعلاه، باستخدام مرشح rcs-keyword.smudge، غير صحيحة.يقوم بإدراج وقت/تاريخ الخروج، أو أي شيء يؤدي إلى تشغيله.

Answer 3

فيما يلي نموذج مشروع يحتوي على كود التكوين والتصفية اللازم لإضافة دعم الكلمات الأساسية لـ RCS إلى مشروع git:

https://github.com/turon/git-rcs-keywords

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

Answer 4

يمكنك تعيين سمة المعرف على ملفاتك، ولكن ذلك من شأنه أن ينتج سلاسل مثل

$Id: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef$

أين deadbeef... هو sha1 للنقطة المقابلة لهذا الملف.إذا كنت حقًا بحاجة إلى توسيع الكلمة الرئيسية، وتحتاج إليه في git repo (على عكس الأرشيف المُصدَّر)، فأعتقد أنه سيتعين عليك استخدام ident gitattribute ببرنامج نصي مخصص يقوم بالتوسيع نيابةً عنك.المشكلة في مجرد استخدام الخطاف هي أن الملف الموجود في شجرة العمل لن يتطابق مع الفهرس، وقد يعتقد git أنه تم تعديله.