رقم مراجعة التخريب عبر مشاريع متعددة

https://stackoverflow.com/questions/15674

08-06-2019
|

سؤال

عند استخدام Subversion (svn) للتحكم بالمصادر مع مشاريع متعددة، لاحظت أن رقم المراجعة يزداد عبر جميع أدلة مشاريعي.لتوضيح تخطيط svn الخاص بي (باستخدام أسماء مشاريع وهمية):

    /NinjaProg/branches
              /tags
              /trunk
    /StealthApp/branches
               /tags
               /trunk
    /SnailApp/branches
             /tags
             /trunk

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

السؤال هو هذا: هل من الممارسات المقبولة الشائعة، عند صيانة مشاريع متعددة باستخدام خادم Subversion واحد، زيادة عدد مراجعة المشاريع غير ذات الصلة عبر جميع المشاريع؟ أم أنني أفعل ذلك بشكل خاطئ ويجب إنشاء مستودعات فردية لكل مشروع؟أم هو شيء آخر تماما؟

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

هل يجب أن أقوم بتخزين جميع المشاريع في مستودع واحد أم في عدة مستودعات؟

مستودع SVN واحد أم أكثر؟

المحلول

أنا مندهش أنه لم يتم ذكر أن هذا تمت مناقشته في التحكم في الإصدار مع التخريب، وهو متاح مجانًا عبر الإنترنت، هنا.

لقد قرأت عن هذه القضية منذ فترة ويبدو أنها مسألة اختيار شخصي، وهناك تدوينة جيدة حول هذا الموضوع هنا.يحرر: نظرًا لأن المدونة تبدو معطلة، (النسخة المؤرشفة هنا) ، إليك بعض ما قاله مارك فيبارد حول هذا الموضوع.

هذه بعض مزايا نهج المستودع الفردي.

إدارة مبسطة.مجموعة واحدة من الخطافات للنشر.مستودع واحد للنسخ الاحتياطي.إلخ.

مرونة الفرع/العلامة.مع وجود الكود في مستودع واحد، فإنه يسهل إنشاء فرع أو علامة تتضمن مشاريع متعددة.

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

وفيما يلي بعض عيوب نهج المستودع الواحد، ومزايا نهج المستودعات المتعددة.

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

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

صلاحية التحكم صلاحية الدخول.على الرغم من أن آلية المصادقة الخاصة بـ Subversion تسمح لك بتقييد الوصول حسب الحاجة إلى أجزاء من المستودع، إلا أنه لا يزال من الأسهل القيام بذلك على مستوى المستودع.إذا كان لديك مشروع لا ينبغي إلا لعدد قليل من الأفراد الوصول إليه، فمن الأسهل القيام بذلك باستخدام مستودع واحد لهذا المشروع.

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

عندما تفكر حقًا، فإن أرقام المراجعة في مستودع المشروعات المتعددة سترتفع، لكن لن تنفد.ضع في اعتبارك أنه يمكنك عرض السجل في دليل فرعي ورؤية جميع أرقام المراجعة المتعلقة بالمشروع بسرعة.

نصائح أخرى

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

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

أيضًا، إذا كنت قلقًا من أن إعداد كل مستودع سيستغرق الكثير من الوقت، فابحث في متغير SVNParentPath لملف تكوين Apache.(مرة أخرى، أفترض أنك تستخدم أباتشي.)

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

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

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

لدينا مستودع واحد فقط يحتوي على كل شيء، تمامًا مثل مثالك تمامًا.

لا أستطيع أن أرى أي خطأ في هذا - الشرط الوحيد لرقم المراجعة هو أن يكون كذلك

فريد
الذري
أكبر مما كانت عليه عند تسجيل الوصول الأخير

لا يهم إذا زاد بمقدار 1 أو 50 مع كل التزام بقدر ما أشعر بالقلق.

@جروم:

ثم عندما أبدأ مشروعًا جديدًا أقوم فقط بتشغيل:

svnadmin create /var/www/svn/myproject

أستطيع أن أرى أن هذا يعمل بشكل جيد إذا كان لديك مطور واحد أو اثنين فقط، ولكن ماذا يحدث إذا لم يكن لدى الأشخاص الذين يقومون بإنشاء مشاريع جديدة حق الوصول إلى Shell على خادم SVN ليتمكنوا من إنشاء أدلة ضمن /var/www ؟

يوصى باستخدام مستودع منفصل لكل مشروع.في دليل Apache conf.d لديّ subversion.conf الذي يحتوي على:

<Location /svn>
  DAV svn
  SVNParentPath /var/www/svn

  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /var/www/svn/password
  Require valid-user
</Location>

ثم عندما أبدأ مشروعًا جديدًا أقوم فقط بتشغيل:

svnadmin create /var/www/svn/myproject

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

في مكان عملي، لدينا مستودعان.واحد مع حق الوصول للقراءة العامة، والآخر لكل شيء آخر.سأستخدم واحدًا فقط لكل شيء، ولكننا نحتاج إلى حقوق وصول مختلفة للمشاريع العامة/الخاصة.

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

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

بالنسبة لي، السبب الرئيسي لاستخدام مستودعات مختلفة هو توفير تحكم منفصل في الوصول للمستخدمين و/أو استخدام نصوص ربط مختلفة.

ربما يكون من الأفضل عدم إجراء ريبو واحد بالضرورة لكل "مشروع"، بل ريبو واحد لكل "حل" (لاستخدام مصطلحات Visual Studio).إذا كان لديك مجموعة من "المشاريع" في مجلدات مختلفة ولكنها مرتبطة ببعضها البعض، فضعها في نفس الريبو.

أقوم بتخزين مشروع واحد لكل مستودع، ومثل المشروع السابق commenter على هذا سؤال التخريب, ، أقوم بوضع علامة على المشاريع المشتركة على أنها خارجية، بحيث تكون في التحكم بالمصادر مرة واحدة فقط.

لقد بدأت للتو في إضافة خادم بناء CI (CruiseControl.NET)، لذا يجب أن أرى كيف يعمل كل ذلك، ولكن إذا كانت نصوص الإنشاء الخاصة بي صحيحة، فلا ينبغي أن تكون هناك مشكلة.

بخلاف المظهر، فهي في الحقيقة مسألة تفضيل (في رأيي).

عندما تفكر حقًا ، ستصبح أرقام المراجعة في مستودع مشروع متعدد المشروع مرتفعًا ، لكنك لن تنفد.ضع في اعتبارك أنه يمكنك عرض تاريخ على دليل فرعي وترى بسرعة جميع أرقام المراجعة التي تتعلق بالمشروع.

في الواقع، إذا كنت تقوم ببناء كود Microsoft الخاص بك، وتستخدم أرقام مراجعة svn كجزء من سلسلة الإصدار الخاصة بك، فمن الممكن أن تنفد.سيقوم برنامج التحويل البرمجي لـ Microsoft بإلقاء خطأ إذا كان أي جزء من سلسلة الإصدار أكبر من 65535....في حالتنا لدينا مستودع ضخم في المراجعة 68876 وقد وصلنا للتو إلى هذا الجدار.

مستودع واحد لكل مشروع.

يعد تعليق ستيفن موراوسكي حول CC.NET تعليقًا مثيرًا للاهتمام.سأكون مهتمًا بمعرفة كيفية عمله إذا كنت بحاجة إلى تحديد عدة مستودعات للتحكم بالمصادر.

@دانيال فون:توصي مستندات SVN بمشروع واحد لكل مستودع، لذا فهذه بالتأكيد هي الطريقة التي أراد المبدعون اتباعها.نظرًا لأنه يمكن أن يكون لديك خادم واحد (Apache أو svnserve) يحتفظ بمستودعات متعددة، لم أواجه أبدًا مشكلة تتعلق بالحمل الزائد.مع خادم فيسوال إس في إن, ، يعد تثبيت خادم Apache وتكوين مستودعات متعددة أمرًا سهلاً.

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

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

واجهت نفس المشكلة في شركتي السابقة، حيث كان لديهم ما يقرب من 50 مشروعًا قيد التشغيل في مستودع واحد وكان العمل على نفس المشاريع بمثابة كابوس لأنه عند إجراء تحديثات svn، قد يلعن الآخرون .... lol...

لقد تعلمت شيئًا واحدًا يعمل دائمًا بشكل أفضل، وهو مشروع واحد One Repo.... لن تندم عليه أبدًا.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow