هل من الممكن استيراد مستودع سلامة MKS إلى جيت؟

Question

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

1. الحصول على الالتزام أولا وإضافته إلى git
2. الحصول على cp المقبل
3. الحصول على فرق ل CP
4. تطبيق فرق إلى جيت العمل دير
5. إضافة والالتزام التغييرات إلى git
6. كرر مع (2.) حتى آخر CP

يمكنك أيضا إعادة تقييم حزمة التغيير مع نقطة تفتيش (سيكون جيدا بما فيه الكفاية بالنسبة لي).

طريقة أبسط ستكون فقط عند الخروج من CP وإضافة / الالتزام إلى GIT. ولكن بعد ذلك سوف تفقد المسار الإضافي وإزالة وحرك وإعادة تسمية العمليات.

هل يعرف أحد كيفية الحصول على فرق موحد من "SI Diff"؟ هذا من شأنه أن يساعد بالفعل الكثير.

أيه أفكار؟

Edit2:
وأضاف إجابة تظهر كيف فعلت بالفعل الهجرة ...

Answer 1

المشكلة مع mks النزاهة هو مستودع فريد من نوعه كل شيء يقيم:

• المتطلبات،
• خطط الاختبار،
• حالات تجريبية،
• الميزات،
• مهام المطور،
• طلبات النشر

نظرا لأن هذه البيانات يمكن أن تتطور بشكل مستقل من شخص آخر، فإن استيرادها جميعا في مستودع جيت واحد سيكون فكرة سيئة: يمكنك استنساخ فقط الكل محتوى Repo Git (حتى لو كان يمكنك الحد من عمق هذا الاستنساخ).
هذا يعني أنك ستحصل على جميع المستندات، على الرغم من أنك مهتم فقط في التعليمات البرمجية.
من شأن تصدير تكامل MKS يعني تحديد أول العديد من المستودعات الجيطية للعمل نقل الأسفل.

---

أحتاج فقط شجرة المصدر وتاريخها.

كالعادة، أود أن أوصي باستيراد فقط:

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

وأنا لا استيراد كل شيء واحد مستودع git إلا إذا كنت واثقا من أن جميع المصادر الخاصة بك تمثل واحد وضع النظام ككل (وليس العديد من الوحدات "الوحدات" المتقدمة بشكل مستقل)

طريقة أبسط ستكون فقط عند الخروج من CP وإضافة / الالتزام إلى GIT.

ستكون هذه هي الطريقة للمضي قدما.

ولكن بعد ذلك سوف تفقد المسار الإضافي وإزالة وحرك وإعادة تسمية العمليات.

رقم! أنت لن! git will. المخاطر تلك العمليات.
هذه هي ميزة كونها ملف محتوى VCS..

Answer 2

لا يمكنني نشر البرنامج الفعلي كتبت، لأنني لم أفعل ذلك في وقتي. ومع ذلك، يمكنني نشر كيف فعلت ذلك. يجب أن يكون من السهل إعادة ذلك مع أي لغة نصية. وهاجرت الأداة التي كتبت فرع واحد فقط في وقت واحد. أود أن أقول ذلك الفرع الذي أريده (على سبيل المثال 1.21.1) والبداية والنهاية في الفرع (على سبيل المثال 4 و 78 ستهاجح جميع المراجعات بدءا من 1.21.1.4 حتى 1.21.1.78). للحصول على جميع الفروع في repo واحد، أود أن أقدم دليل .git لاستخدامه للاستيراد فيه.

• بدء حلقة من بدء المراجعة لإنهاء المراجعة
  • currentrev = branch.loopcounter.
  • إنشاء دليل الريبو
  • نقل .git dir إلى دليل الريبو
  • نقل ملف .gitignore إلى دليل الريبو
  • Chdir في دليل الريبو
  • إنشاء MKS Sandbox داخل Repo Dir عبر "Si Createsandbox -P MKS_Project_Path - Yees - Probojectrevision = CurrentRev
  • جلب وصف مراجعة عبر "SI ViewProjecthistory - Rfilter = Range: Currentrev-CurrentRev"، إخراج الالتقاط!
  • استخراج المستخدم والتاريخ والعلامات (الملصقات) والتعليقات من الإخراج السابق
  • "بوابة إضافة".
  • معلومات المستخرجة الأنابيب من أعلى إلى "ارتكاب GIT--AF -" (لا يمكن القيام به - إذا كنت تريد خطوط متعددة مثل تعليق نقطة التفتيش)
  • إسقاط Sandbox عبر "Si dropsandbox - yourder.pj"
  • نقل .git و .gitignore إلى مكان حفظ (للتكرار التالي)
  • احذف جميع الملفات المتبقية في دليل Sandbox
  • الانتقال إلى الوالد دير (..)
  • حذف Sandbox / Repo Dir
• إنشاء أخيرة جيت دير
• نقل .git و .gitignore في نهائي جيت دير
• "جيت إعادة تعيين الرأس"

منجز.

يستخدم MKS نوعا من ترميز ASCII الخاص بسلسلةه وعادة ما يستخدم GIT UTF-8 حتى تتمكن من المشكلة عند استيراد بيانات META في GIT (أسماء المستخدمين والتعليقات والعلامات وما إلى ذلك).

لمزيد من الفروع القيام بذلك:

• في دليل GIT، تحقق من المراجعة حيث يجب أن يبدأ الفرع وإنشاء فرع ("GIT Checkout -B Newbranchname")
• الانتقال الآن .git و .gitignore إلى مكان حفظ وحذف دير كله
• الآن تفعل نفس الشيء على النحو الوارد أعلاه

شيء آخر: "SI" هو أداة سطر الأوامر MKS. لذلك تحتاج إما إلى تحديد مسارها الكامل أو وضع مسارها في مسار البحث.

Answer 3

FWIW، SI DIFFAF للأسف لا يدعم حاليا فرق موحد. هناك طلب للتغيير لفعل ذلك، ولكن لم يكن هناك الكثير من العملاء حتى الآن يطلبوا هذه الميزة.

إخلاء المسئولية: أعمل من أجل PTC (الذي حصل MKS).

Answer 4

هذا يعمل مع نقاط التفتيش ...

https:/gist.gist.github.com/2369049.

لسوء الحظ، يبدو أن نقاط التفتيش على ما يبدو الشيء الوحيد الذي يجعل أي معنى من MKS -> GIT، حيث أن نقطة تفتيش هي حقا أقرب شيء إلى "لقطة" التي تستدعي GIT الالتزام.

MKS لديها الكثير من المفاهيم غير المتوافقة (لكل تتبع إصدار الملفات، فروع لا تشبه فروع git ونقاط التفتيش، وما إلى ذلك) والتي يمكن أن تطور جميعها بشكل مستقل عن بعضها البعض من الصعب حقا معرفة كيفية ترحيل محفوظات معقولة في git. ربما هناك العديد من الطرق للقيام بذلك ولا أحد منهم أكثر "صحيحة" من التالي.

ومع ذلك، أحب أن أسمع بعض الأفكار الجيدة. :)

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

Answer 5

يمكنني استخدام هذه الأداة لاستيراد حزم التغيير من MKS إلى Mercurial، استيرادها إلى GIT يجب أن تكون متشابهة تماما؛ أو يمكنك استيرادها إلى Mercurial First، واستخدم أداة GIT لاستيراد Mercurial Next.

https://github.com/arsane/py-mks2hg.git.

سيحاول معرفة جميع حزم التغيير التي بموجب المشروع المحدد، والالتزام بالمستودع الزئبقي الجديد بالترتيب.