التحرير الموضعي والتحكم في الإصدار - ما هو الحل الذي تفضله؟

Question

أنا أستخدم SVN لمهام التطوير، ولكن لا يزال لدي العديد من الملفات المُدارة باستخدام RCS، لأنه لا يبدو من المعقول تحريرها في نسخة عمل مستودع SVN الخاص (نظرًا لأنها غالبًا ما تكون مجرد ملفات تكوين من الأفضل أيضًا اختبارها في مكانها) ).كما أنه لا يبدو من المعقول أن يكون لديك نسخة عمل من المستودع أينما توجد ملفات لوضعها تحت تحكم SVN، لذلك أستخدم RCS بدلاً من ذلك.

ما هو النهج الذي تتبعه لإدارة الملفات التي لا ينبغي نقلها بشكل مثالي أو تحريرها واختبارها في مكانها؟

كي تكون اكثر دقة:أود الحصول على ما يعادل

• وجود ملف محمي ضد الكتابة.txt
• أمر مثل "co -l file.txt" (RCS) لجعله قابلاً للتحرير
• إمكانية تعديله في مكانه واختباره فورًا
• أمر مثل "ci -u file.txt" (RCS) لتسجيل التغيير وإضافة تعليق وجعله للقراءة فقط مرة أخرى
• يجب أن يكون المستخدمون الآخرون أيضًا قادرين على القيام بذلك في نفس المكان
• ولكن، يجب أن تنتقل معلومات الإصدار إلى مكان آمن (من المفترض أن يكون ممثل svn)، على خادم مختلف

Answer 1

أستخدم النسخ على أنظمة ملفات الكتابة (CoW) مثل Ext3cow (إخلاء المسؤولية، أنا أحد المساهمين فيها) لإدارة الكثير من الأشياء.على سبيل المثال:

• استخدام اللقطات لاستعادة المستودعات بأكملها، بغض النظر عن نوعها.على سبيل المثال، إذا قمت بإفساد شجرة git تمامًا، فيمكنني cp -dpfR ./@123456789 ./ ، والذي يستبدل الريبو العامل الخاص بي بالملفات تمامًا كما كانت في العصر 123456789.
• استخدام الإصدارات/اللقطات باعتبارها VCS الخاصة بها غير القابلة للتغيير، مثالية لـ /etc وأشياء أخرى.نظرًا لأن الملفات الموجودة في الماضي لا يمكن حذفها أو تعديلها، فإن كل لقطة هي مراجعة غير قابلة للتغيير لملف واحد أو للشجرة بأكملها في الوقت المناسب.

عادة، أستخدم Git أو Mercurial بدلاً من Subversion لأنني أفضل إصدار VCS الموزع، لكنني أصر الآن على الاحتفاظ بمستودعاتي على إصدار FS محليًا.

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

Answer 2

كما قيل من قبل، فأنت تحاول استخدام SVN لشيء يجب أن يستخدم DVCS مثل git أو Mercurial.

يمكن لأي شخص أن يكون لديه مستودعه الخاص، ثم يقوم بمزامنته مع الريبو المركزي (مثل SVN repo).

وهذا في الواقع ما أستخدمه في مشاريعي الخاصة.

الشيء الوحيد الذي لم أفهمه هو سبب حاجتك للأقفال.ليس من الضروري أن يكون الملف للقراءة فقط.ربما تفكر بهذه الطريقة بسبب الطريقة التي يتم بها دمج SVN (يجب عليك دائمًا القيام بذلك يدويًا).يقوم Git بالسحر حقًا[1] وتتم غالبية عمليات الدمج دون تدخل بشري.

[1] طيب، ليس سحرا.بينما يهتم SVN بالملفات، يهتم Git بأجزاء من التعليمات البرمجية.بهذه الطريقة يمكن دمج ملف تم تغييره مرتين في نفس الوقت، طالما أنك لا تغير بالضبط نفس قطعة التعليمات البرمجية.

Answer 3

تعد أنظمة التحكم في الإصدارات الموزعة الحديثة مثل Git أو Mercurial أو Bazaar هي أفضل أداة في مثل هذا الموقف.ليس بسبب الجانب الموزع (والذي من الواضح أنه ليس حاسما هنا)، ولكن لأنه من السهل للغاية إنشاء مستودع في مكانه.

في Mercurial ما عليك سوى القيام بما يلي:

cd ~/directory
hg init

مع Git مشابه:

cd ~/directory
git init
git add .

كل نسخة عاملة هي مستودع كامل، ويمكنك دفعها إلى خادم بعيد كنسخة احتياطية إذا أردت.علاوة على ذلك، يتم تخزين جميع بيانات المستودع في دليل مخفي واحد، لذلك تتجنب مشكلة وجود الكثير منها .svn الدلائل في كل مكان.

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

Answer 4

عليك أن تدرك أن مستودعات SVN مجانية.يمكنك إنشاء العدد الذي تريده.

عليك أيضًا أن تدرك أنه ليس عليك التحقق من مستودع كامل.أنت قلت:

كما أنه لا يبدو من المعقول أن يكون لديك نسخة عمل من المستودع أينما توجد ملفات لوضعها تحت التحكم في SVN

لست متأكدًا مما تحاول فعله حقًا، ولكن لدي انطباع بأنك تستخدم SVN بطريقة غريبة.