سؤال

اعتدت استخدام SVN 1.4 على OS X Leopard وكان كل شيء على ما يرام. قبل أسبوعين قمت بتثبيت نسخة جديدة من OS X 10.6. إصدار SVN الذي يأتي مع Snow Leopard هو 1.6.5. تقدمت وقمت ببناء نسختي الخاصة مع 1.6.6. أنا أستخدم خادم Apache المدمج وأستضيف المستضافة محليًا.

بدا أن كل شيء يعمل بشكل جيد حتى حاولت بالفعل ارتكاب شيء ما. في كل مرة أحاول أن ألتزم بها تغيير ، أحصل على الرسالة التالية:

Transmitting file data .svn: Commit failed (details follow):
svn: MERGE of '/svn/svn2': 409 Conflict (http://localhost)

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

يقوم خطأ Apache بتسجيل ما يلي لكل الالتزام الفاشل:

[Mon Mar 29 19:53:10 2010] [error] [client ::1] Could not MERGE resource "/svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1" into "/svn/svn2".  [409, #0]
[Mon Mar 29 19:53:10 2010] [error] [client ::1] An error occurred while committing the transaction.  [409, #2]
[Mon Mar 29 19:53:10 2010] [error] [client ::1] Can't open directory '/usr/local/svn/svn2/db/transactions/5-6.txn/\xeb\xa9\x0f\x1f': No such file or directory  [409, #2]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Could not DELETE /svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1.  [500, #0]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] could not open transaction.  [500, #2]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Can't open file '/usr/local/svn/svn2/db/transactions/5-6.txn/props': No such file or directory  [500, #2]

ومن سجل الوصول:

::1 - - [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 401 401
::1 - user [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 200 188
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/vcc/default HTTP/1.1" 207 398
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/bln/6 HTTP/1.1" 207 449
::1 - user [30/Mar/2010:13:02:20 -0400] "REPORT /svn/svn2/!svn/vcc/default HTTP/1.1" 200 1172

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

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

أي مساعدة سيكون موضع تقدير كبير.

تحديث
لقد حاولت إضافة Autoversioning إلى ملف svn.conf الخاص بي. هذا ما تقوله ملفاتي:

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so
<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  SVNAutoversioning on

  # how to authenticate a user
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /usr/local/etc/svn-auth-file

  # only authenticated users may access the repository
  Require valid-user
</Location>    

تحديث (الحل)

أردت فقط تحديث هذا من خلال الحل الفعلي في حالة تواجد أي شخص آخر نفس المشكلة مع رسائل الخطأ غير المفيدة تمامًا. كانت المشكلة مع أجزاء APR و APR-UTIL (كما اقترح شيراند). كنت أقوم ببناء نسخة من كلاهما باستخدام حزمة تبعية التخريب. OS X 10.6 يحتوي أيضًا على نسخته الخاصة. وكان كلا الإصدارين 1.3.8. على ما يبدو ، كنت بحاجة إلى استخدام الإصدارات التي يستخدمها تثبيت Apache الافتراضي.

لذلك ، قمت بحذف مجلدات APR و APR-UP-UTIL من بناء التخريب الخاص بي ، للتأكد من أنني لم أكن أقوم ببناء نسختي الخاصة من هذه مرة أخرى. لقد قمت ببناء SVN من المصدر مرة أخرى ، هذه المرة باستخدام التكوين التالي:

./configure --with-apr=/usr/bin/ --with-apr-util=/usr/bin/ --with-ssl

بعد البناء مرة أخرى ، قمت بإعادة تشغيل Apache ، وأنشأت ريبو SVN جديد. تمكنت من التحقق من ذلك ، وإجراء التغييرات ، والالتزام دون أي مشاكل. ثم جربت repos القديمة وأولئك الذين عملوا كذلك.

شكرا جميعكم للمساعدة!

هل كانت مفيدة؟

المحلول

أنا على ثلج رفيع جدًا هنا (409 غير محدد للغاية) لكنني قادر على صياغة سؤالين:

  1. هل هناك أي خطافات قبل أو ما بعد الالتزام في مكانها؟
  2. هو "التلقائي"ممكّن؟

إذا كانت هناك أي خطافات ، هل أنت متأكد من أنها لا تحتوي على أي أخطاء؟ هل يمكنك تعطيلها للاختبار؟ إذا لم يتم تمكين عملية التلقائية ، فهل يمكنك محاولة تمكينها للاختبار؟ هذا يجب أن يعمل على غرار

<Location /repos>
  DAV svn
  SVNPath /var/svn/repository
  SVNAutoversioning on
</Location>

عند استخدام mod_dav_svn (انظر الرابط إلى Autoversioning أعلاه).

ربما يساعد هذا في إلقاء بعض الضوء على مشكلتك ويمكننا (و/أو Google :)) أن نأخذه من هناك.

راجع للشغل: السجلات التي نشرتها ليست من نفس الالتزام ، أليس كذلك؟ سيكون اختلاف الوقت ضخمًا؟!؟

يحرر:الاعتذار إذا وجدت ذلك منذ فترة طويلة ، لكنني سأعطيها لقطة: لا يمكن دمج مورد على الالتزام (Apache 2.0.55) هو شيء وجدته Google بالنسبة لي :)

يكتب OP هناك أن "Apache تملي نسخة من أبريل لاستخدام ". هذا يعني أنه يجب عليك الرجوع إلى النسخ الصحيح APR عند تجميع SVN. لقد قمت بتثبيت SVN (v1.6.9) من خلال macports على نظامي (OS X 10.6). أنا لا أستخدم WebDav أو Apache محليًا ، لكن لدي 1.3.12_1 APR مثبت (فقط للرجوع). يشير المرجع إلى الاستخدام --with-apxs=/path/to/bin/apxs عند تجميع SVN على الرغم من أنني لست متأكدًا مما إذا كان هذا ينطبق على موقفك (بدأت في التخمين منذ فترة طويلة ، قد تلاحظ :)).

أي فرصة يمكنك التحقق من APR-Version التي يتوقعها Apache مقابل الشخص المستخدم لإنشاء SVN (على سبيل المثال ، يمكنك استخدامه sudo port installed apr لمعرفة ما الذي تعيشه أفعال APR على نظامك إذا كنت تستخدم Macports)؟

فقط للإشارة إلى مقتطف من بناء أباتشي بالطريقة التي تريدها:

apxs هي الأداة المساعدة المستقلة لتجميع الوحدات النمطية ديناميكيًا دون الحاجة إلى استخدام configure البرنامج النصي أو احصل على رمز مصدر Apache. إنها تحتاج إلى ملفات رأس Apache ، والتي يتم نسخها إلى الموقع المحدد بواسطة --includedir عندما يتم تثبيت Apache. ومع ذلك ، من المهم استخدام apxsتم تصميمه بنفس خيارات التكوين مثل Apache؛ خلاف ذلك ، فإنه سيضع افتراضات خاطئة حول مكان وجود مواقع التثبيت المختلفة لأباش.

نصائح أخرى

لديّ فكرتان حول المكان الذي قد تختبئ فيه المشكلة ، وهما بالطبع تخمينات برية ، لذلك يتم تحذيرها.

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

الفكرة الثانية هي التحقق من توافق إصدارات SVN للنسخ والخادم--C-CORTER. الرجال من Subversion أقسم أن كلاهما 1.5 و 1.6 لا تقم بتكسير التوافق على مستوى المستودع مع 1.4 (وإن كانوا يفعلون ذلك على نسخ العمل). لكن لن يضر أن تحقق من أن تنسيق المكدس بأكمله ثابت. وبينما كنت في ذلك ، تأكد من أن مكتبات Apache التي قمت ببنائها متوافقة مع Apache 2.2.11 التي تأتي مع 10.6 (مرة أخرى ، ولكن لا تعرف أبدًا)

وأخيرا ، حظا سعيدا.

أولا إنشاء خط الأساس. على مخزون تثبيت Snow Leopard (10.6.3) إليك بالضبط ما فعلته.

تم إنشاء "/etc/apache2/other/svn.conf" مع المحتوى:

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so
<Location /svn>
    DAV svn
    SVNParentPath /usr/local/svn
    AuthType Basic
    AuthName "Subversion repository"
    AuthUserFile /usr/local/svn/htpasswd
    Require valid-user
</Location>

تم إنشاء مجلد تخريب ومستودع "اختبار":

sudo mkdir /usr/local/svn
sudo svnadmin create /usr/local/svn/test
sudo chown -R _www:_www /usr/local/svn
sudo htpasswd -cb /usr/local/svn/htpasswd testuser testpass

من المستخدم العادي ، الدليل المنزلي:

macmini:~ jclark$ mkdir Checkout && cd Checkout
macmini:Checkout jclark$ svn --username testuser checkout http://localhost/svn/test
Authentication realm: <http://localhost:80> Subversion repository
Password for 'testuser':
Checked out revision 0.
macmini:Checkout jclark$ cd test && touch test.txt && svn add test.txt && svn commit -m 'test' test.txt
A         test.txt
Adding         test.txt
Transmitting file data .
Commited revision 1.
macmini:test jclark$

الآن ، إذا كان كل ذلك يعمل كما ينبغي ، فعليك أن يكون لديك مستودع تخريب 1.6.5 يعمل من قبل Apache. إذا لم يكن الأمر كذلك ، فأنت على الأرجح إما خلط ثنائيات/libs SVN المرفوعة من Apple مع (macports ، إلخ) أو هناك مشاكل الأذونات. يجعلون بالتأكيد أنت تستخدم ثنائيات Apple المقدمة. تقوم Apple بتعديل المصدر قليلاً وقد واجهت مشكلات التوافق عند خلط "المنافذ" مع "المخزون" في الماضي. بالنسبة للأذونات ، يعمل Apache كمستخدم _www ، المجموعة _www. تأكد من امتلاك جميع الملفات والأدلة على هذا النحو ، ولا تنسَ تحديثها كلما استخدمت svnadmin أو أي شيء آخر لمعالجة مستودع SVN مباشرة.

نظرًا لأن ذلك يعمل ، فحرك مستودع "SVN2" الخاص بك مرة أخرى إلى/usr/local/svn (إذا لم تكن قد لم تكن بالفعل) ، فقم بإجراء عملية الخروج النظيفة في مكان ما ، وجرب التزام اختبار.

إذا كنت لا تزال تواجه مشاكل ، فحاول ترقية المستودع.

sudo svnadmin upgrade /usr/local/svn/svn2
sudo chown -R _www:_www /usr/local/svn/svn2

كرر اختبار الخروج / الالتزام.

كملاذ أخير ، تفريغ وتحميل المستودع مرة أخرى.

sudo svnadmin dump /usr/local/svn/svn2 > /tmp/svn2.dump
sudo svnadmin create /usr/local/svn/svn3
sudo svnadmin load /usr/local/svn/svn3 < /tmp/svn2.dump
sudo chown -R _www:_www /usr/local/svn/svn3

كرر اختبار الخروج /الالتزام ، هذه المرة مع /svn /svn3.

استمتع بمستودعك الثابت ... نأمل :)

تحديث

قد يكون هناك أ حشرة في عميل سطر أوامر التخريب. بعد القيام:

mkdir \!vcc && touch \!vcc/default
svn add \!vcc && svn commit -m 'test'
svn log

لاحظ أن إخراج سجل SVN (على الأقل بالنسبة لي) ليس شيئًا. سجل SVN من السلحفاة على ما يرام ، مما يشير إلى أن الخادم (كما هو الإعداد أعلاه) يعمل بشكل صحيح.

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

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

chown -R apache:apache svn

chmod -R 770 svn

هذا حل الصراع لي: لقد قمت بعمل نسخة احتياطية من ملفاتي المحلية ، ثم سحب كل شيء من الخادم. ثم ، عندما أدخلت ودفعت ملفات النسخ الاحتياطي ، لم يظهر خطأ الصراع 409 مرة أخرى.

التحيات ، كيفن

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top