ما هي قيمة الالتزامات الذرية في التخريب؟

Question

أحاول إنشاء ومتابعة أفضل الممارسات للتحكم في الإصدار وعثرت على إشارة إلى الالتزامات الذرية في Subversion.نظرًا لأنني لم أسمع بهذا الإجراء من قبل، لدي بعض الأسئلة حول هذا الموضوع.

• ما هو الغرض منه؟
• متى يجب استخدامها؟
• وكيف يختلف عن الالتزام العادي؟
• هل هو متاح ل السلحفاةSVN المستخدمين؟إذا كان الأمر كذلك، كيف؟

Answer 1

لا يوجد أمر خاص للالتزامات الذرية.كل التزام في Subversion هو ذري.

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

وهذا هو نفسه بالنسبة لـ TortoiseSVN، لأنه يعتمد على وظيفة التخريب "العادية".

---

وفيما يلي مقتطف من كتاب التخريب:

An svn commit operation publishes changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents; create, delete, rename, and copy files and directories; and then commit a complete set of changes as an atomic transaction.

By atomic transaction, we mean simply this: either all of the changes happen in the repository, or none of them happens. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.

Answer 2

الفكرة ببساطة هي أن التغييرات التي يتم إجراؤها على ملف واحد عادة ما تكون مرتبطة بالتغييرات في ملف آخر.بعض أنظمة التحكم في الإصدار الأقدم لم تتعامل مع ملفات متعددة في التزام واحد (باعتباره "التزامًا ذريًا" كما تسميه) أو كان أداؤها سيئًا.

ليس عليك أن تفعل أي شيء خاص لهذا الغرض.هذه هي الطريقة التي يعمل بها التخريب.ولكن مع Subversion لديك خيار التحقق من ملف واحد في كل مرة أو القيام بكل الملفات المعدلة مرة واحدة أو في أي مكان بينهما.

إن فكرة تنفيذ ملفات متعددة في التزام واحد هي أنه - بشكل عام - يجب أن تكون قادرًا على التحقق من المستودع في أي إصدار معين وسيتم تجميعه وتشغيله على الأقل.وهذا مهم في الفرق.الآن من الناحية العملية، قد لا يكون هذا صحيحًا بنسبة 100% في كل الأوقات، لكن المبدأ التوجيهي سليم.

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

Answer 3

تشير كلمة "الذرية" في هذه الحالة إلى عملية ذرية.يمكنك العثور على تعريف جيد لذلك هنا:http://en.wikipedia.org/wiki/Atomic_operation

جميع الالتزامات في SVN تكون تلقائية تلقائيًا، لذا تحصل عليها مجانًا في كل مكان تقوم فيه بالتزام.

Answer 4

إذا كنت تريد معرفة ما هي فائدة الالتزامات الذرية، فتخيل أنك تقوم بدمج فرع في صندوق القرص الخاص بك.تبدأ في الصباح وبعد الغداء تنتهي، ويتم تجميع كل شيء، ويتم تشغيل جميع اختبارات الوحدة بنجاح.تقوم بعد ذلك بتنفيذ أكثر من 200 ملف تم تغييرها أثناء هذا الدمج.

في SVN، إما أن ينجح الالتزام ويتم الالتزام بجميع الملفات التي يزيد عددها عن 200 ملف دفعة واحدة، أو يفشل الالتزام ولا يتم إجراء أي تغييرات على المستودع على الإطلاق.(ليس هناك الكثير ليقوله عن هذا.إنها الطريقة التي ينبغي أن تكون عليها دائمًا.)

في CVS، الذي لا يحتوي على التزامات ذرية، يمكن أن يحدث أن تتم مقاطعة التزامك بعد 150 ملفًا بسبب تعثر شخص ما عبر كابل الشبكة الخاص بك، مع عدم الالتزام بالملفات المتبقية التي يزيد عددها عن 50 ملفًا، مما يترك المستودع في حالة متوسطة.أثناء محاولتك توصيل كابل الشبكة، يقوم شخص آخر في فريقك بالتحقق من مجموعة أخرى من التغييرات.مجموعة التغييرات هذه منفصلة عن تلك التي قمت بتسجيل الوصول إليها بالفعل، وبالتالي ينجح التزام الشخص الآخر.ومع ذلك، فإن التغييرات غير متوافقة.الآن أصبح الفريق عالقًا في مستودع يحتوي على تعليمات برمجية لا يتم تجميعها، ناهيك عن اجتياز أي اختبار.ما هو أسوأ:لديكما مدير فريق يراقبك لإصلاح تلك التغييرات غير المتوافقة في أسرع وقت ممكن حتى يتمكن باقي أعضاء الفريق من التوقف عن لعب Quake والعودة إلى العمل.

ومن المثير للدهشة أن مثل هذه السيناريوهات ليست مستبعدة كما قد تبدو.لقد كنت هناك عدة مرات وحصلت على مجموعتي من القمصان الرديئة.

Answer 5

لفهم الاستخدام الحقيقي للالتزام الذري، اقرأ هذا عن التكامل المستمر:

http://en.wikipedia.org/wiki/Continious_integration

يتعلق الاستخدام حقًا بضمان إمكانية التراجع عن جميع التغييرات التي أجراها مطور معين في حالة حدوث مشكلة في التكامل.هذه ميزة قوية جدًا في الحفاظ على سلامة الكود في المستودع.