هل ينبغي أن يكون .sln ملتزمًا بالتحكم بالمصادر؟
https://stackoverflow.com/questions/1033809
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
هل من أفضل الممارسات الالتزام بملف .sln للتحكم بالمصادر؟متى يكون من المناسب أو غير المناسب القيام بذلك؟
تحديثكانت هناك عدة نقاط جيدة في الإجابات.شكرا على الردود!
المحلول
أعتقد أنه من الواضح من الإجابات الأخرى أن ملفات الحلول مفيدة ويجب الالتزام بها، حتى لو لم يتم استخدامها للإصدارات الرسمية.إنها سهلة الاستخدام لأي شخص يستخدم ميزات Visual Studio مثل Go To Definition/Declaration.
افتراضيًا، لا تحتوي على مسارات مطلقة أو أي عناصر أخرى خاصة بالجهاز.(لسوء الحظ، لا تحافظ بعض أدوات الوظائف الإضافية على هذه الخاصية بشكل صحيح، على سبيل المثال، AMD CodeAnalyst.) إذا كنت حريصًا على استخدام المسارات النسبية في ملفات مشروعك (كل من C++ وC#)، فستكون مستقلة عن الجهاز أيضاً.
ربما السؤال الأكثر فائدة هو:ما هي الملفات التي يجب عليك استبعادها؟إليك محتوى ملف .gitignore الخاص بي لمشاريع VS 2008 الخاصة بي:
*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/
(الإدخال الأخير مخصص فقط لملف تعريف AMD CodeAnalyst.)
بالنسبة لـ VS 2010، يجب عليك أيضًا استبعاد ما يلي:
ipch/
*.sdf
*.opensdf
نصائح أخرى
نعم - أعتقد أنه مناسب دائمًا.الإعدادات الخاصة بالمستخدم موجودة في ملفات أخرى.
نعم يجب عليك أن تفعل هذا.يحتوي ملف الحل على معلومات فقط حول البنية العامة للحل الخاص بك.تعتبر المعلومات عامة بالنسبة للحل ومن المحتمل أن تكون مشتركة بين جميع المطورين في مشروعك.
لا يحتوي على أي إعدادات خاصة بالمستخدم.
يجب أن يكون لديك بالتأكيد.إلى جانب الأسباب التي ذكرها الآخرون، هناك حاجة إلى اتخاذ خطوة واحدة لبناء المشاريع بأكملها الممكنة.
أوافق عمومًا على ضرورة فحص ملفات الحلول، ولكن في الشركة التي أعمل بها قمنا بشيء مختلف.لدينا مستودع كبير إلى حد ما ويعمل المطورون على أجزاء مختلفة من النظام من وقت لآخر.لدعم الطريقة التي نعمل بها، سيكون لدينا إما ملف حل كبير أو عدة ملفات أصغر.كلاهما لهما بعض أوجه القصور ويتطلبان عملاً يدويًا من جانب المطورين.ولتجنب ذلك، قمنا بإنشاء مكون إضافي يتعامل مع كل ذلك.
يسمح المكون الإضافي لكل مطور بفحص مجموعة فرعية من شجرة المصدر للعمل عليها ببساطة عن طريق تحديد المشاريع ذات الصلة من المستودع.يقوم البرنامج المساعد بعد ذلك بإنشاء ملف حل وتعديل ملفات المشروع بسرعة للحل المحدد.كما أنه يتعامل مع المراجع.بمعنى آخر، كل ما يتعين على المطور فعله هو تحديد المشاريع المناسبة ومن ثم يتم إنشاء/تعديل الملفات الضرورية.يتيح لنا هذا أيضًا تخصيص إعدادات أخرى مختلفة لضمان معايير الشركة.
بالإضافة إلى ذلك، نستخدم البرنامج الإضافي لدعم سياسات تسجيل الوصول المختلفة، والتي تمنع المستخدمين عمومًا من إرسال تعليمات برمجية خاطئة/غير متوافقة إلى المستودع.
نعم الأشياء التي يجب عليك الالتزام بها هي:
- الحل (*.sln)،
- ملفات المشروع،
- جميع الملفات المصدرية،
- ملفات تكوين التطبيق
- بناء البرامج النصية
الأشياء التي يجب عليك لا الالتزام هي:
- ملفات خيارات مستخدم الحل (.suo)،
- إنشاء الملفات التي تم إنشاؤها (على سبيل المثال.باستخدام برنامج نصي للبناء) [يحرر:] - فقط إذا كانت جميع البرامج النصية وأدوات البناء الضرورية متاحة تحت التحكم في الإصدار (للتأكد من أن الإصدارات أصلية في سجل السير الذاتية)
فيما يتعلق بالملفات الأخرى التي يتم إنشاؤها تلقائيًا، هناك ملف موضوع منفصل.
نعم، يجب أن يكون جزءًا من التحكم بالمصادر.عندما تقوم بإضافة أو إزالة مشاريع من التطبيق الخاص بك، سيتم تحديث .sln وسيكون من الجيد أن يكون تحت التحكم بالمصادر.سيسمح لك بسحب الإصدارين من رمز التطبيق الخاص بك مرة أخرى وإجراء الإنشاء مباشرة (إذا كان ذلك مطلوبًا على الإطلاق).
نعم، تريد دائمًا تضمين ملف .sln، فهو يتضمن روابط لجميع المشاريع الموجودة في الحل.
في معظم الحالات، من الجيد إرسال ملفات .sln إلى التحكم بالمصادر.
إذا تم إنشاء ملفات .sln الخاصة بك بواسطة أداة أخرى (مثل CMake)، فمن غير المناسب وضعها في التحكم بالمصادر.
نحن نفعل ذلك لأنه يبقي كل شيء متزامنًا.جميع المشاريع الضرورية موجودة معًا، ولا داعي للقلق بشأن فقدان أحدها.يستخدم خادم البناء الخاص بنا (Ant Hill Pro) أيضًا sln لتحديد المشاريع التي سيتم إنشاؤها للإصدار.
عادةً ما نضع جميع ملفات الحلول لدينا في دليل الحلول.بهذه الطريقة نفصل الحل عن الكود قليلًا، وسيكون من الأسهل اختيار المشروع الذي أحتاج للعمل عليه.
الحالة الوحيدة التي قد تفكر فيها في عدم تخزينها في التحكم بالمصادر هي إذا كان لديك حل كبير يتضمن العديد من المشاريع التي كانت في التحكم بالمصادر، وأردت إنشاء حل صغير مع بعض المشاريع من الحل الرئيسي للبعض متطلبات عابرة خاصة.
نعم - يجب أن يكون كل شيء مستخدم لإنشاء منتجك تحت التحكم بالمصادر.
نحتفظ أو نحل الملفات في التحكم في إصدار TFS.ولكن نظرًا لأن الحل الرئيسي كبير جدًا، فإن معظم المطورين لديهم حل شخصي يحتوي فقط على ما يحتاجون إليه.يتم استخدام ملف الحل الرئيسي في الغالب بواسطة خادم الإنشاء.
.slns هي الشيء الوحيد الذي لدينا لم تفعل ذلك كان لديه مشاكل مع في TFS!
1) إنشاء مشروع جديد في VS
2) انقر بزر الماوس الأيمن على الحل في Solution Explorer، وحدد Add to Source Control
هل يتم إضافة sln إلى التحكم بالمصادر؟هذه هي إجابتك.
