Помилка підриву: сховище переміщено назавжди, щоб просити його перемістити


23

Я встановив на моєму сервері subversion і apache.

Якщо я переглядаю його через веб-браузер, він працює чудово ( http://svn.host.com/reposname ). Однак якщо я роблю замовлення на своїй машині, я отримую таку помилку:

Command: Checkout from http://svn.host.com/reposname, revision HEAD, Fully recursive, Externals included  
Error: Repository moved permanently to 'http://svn.host.com/reposname/'; please relocate  

Я перевірив журнал помилок apache, але він нічого не говорить. (це зараз - див. редагувати)

Мої сховища зберігаються під: / var / www / svn / repos /

Мій веб-сайт зберігається під: / var / www / vhosts / x / ...

Ось конф-файл для піддомену:

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

   AuthType Basic
   AuthName "Authorization Realm"
   AuthUserFile /var/www/svn/auth/svn.htpasswd
   Require valid-user
</Location>

Аутентифікація працює чудово.

Хтось знає, що може бути причиною цього?

- Редагувати

Тому я перезапустив apache (знову) і спробував його ще раз, і тепер він дає мені повідомлення про помилку, але це не дуже допомагає. Хтось має уявлення, що це означає?

[Wed Mar 31 23:41:55 2010] [error] [client my.ip.he.re] Could not fetch resource information.  [403, #0]
[Wed Mar 31 23:41:55 2010] [error] [client my.ip.he.re] (2)No such file or directory: The URI does not contain the name of a repository.  [403, #190001]

- Редагувати 2

Якщо я svn infoце зробити, це не дає нічого корисного:

[root@server domain.com]# svn info http://svn.domain.com/repos/
Username: username
Password for 'username':
svn: Repository moved permanently to 'http://svn.domain.com/repos/'; please relocate

Я також спробував зробити місцевий замовлення ( svn checkout file:///var/www/svn/repos/reposname), і це працює чудово (також додавання / фіксація працює добре). Тож, здається, має щось спільне з апашем.

Деякі інші відомості:

  • Я працюю CentOs 5.3
  • Плеск 9.3
  • Subversion, версія 1.6.9 (r901367)

- Правка 3

Я спробував перемістити сховища, але це не мало значення.

selinux відключений, так що це не так.


1
Чому у вас Options +indexesце не повинно насправді нічого корисного робити у svn-місці.
Зоредаче

Ви намагалися тимчасово відключити щось, що стосується автентифікації / авторизації?
Зоредаче

Я намагався зробити так, щоб він показав мені огляд усіх сховищ (пізніше я дізнався, що для цього є інша команда), я її видалив. Я також видалив автентифікацію, але це нічого не вирішило (Auth насправді працює нормально, він запитує у мене ім’я користувача / пароль і приймає лише реальну комбінацію).
Барт С.

Відповіді:


22

У мене це було недавно ... але виявилося, що я забув URL-адресу :)

Одне, що вам потрібно зробити, - це переконатися, що ваше місцезнаходження SVN не перекриває жодні веб-сайти, які підтримуються апачем. наприклад, якщо ви встановите DocumentRoot на / www, а ваше svn-місцезнаходження - на / www / svn ..., тоді у вас виникли проблеми - Apache не дізнається, з чим його потрібно подавати (тобто спеціальні обробники svn або прямий обробник http).

Для цього дивіться запис FAQ .


Здається, це може бути правильною відповіддю, але ось ще одна можлива публікація, пов’язана з цим: forum.webfaction.com/viewtopic.php?id=2423 .
Пол Крон

1
Нічого собі, я вже знав про це, але думав, що спробую ще раз. Я створив нове сховище, і це спрацювало. Мене збентежило, чому це сталося, тому я FTP'd на свій сервер і дізнався, що в каталозі httpdocs піддомен (створений plesk), який називається test (там же), як у моєму сховищі, був каталог. Я його видалив, і тепер він працює. Дякую за допомогу.
Барт С.

1
Щоб детальніше розробити один загальний сценарій. Якщо у вас є віртуальне налаштування хоста і ви хочете, щоб SVN був у корені (наприклад, svn.example.com - це ваша URL-адреса репо), НЕ встановлюйте "DocumentRoot / svn" і не використовуйте блок "<Каталог / svn>" у вашій VirtualHost для налаштуйте параметри DAV svn для кореневого шляху. Це спричинить проблему, коли Apache плутається між обробником DAV та його внутрішніми обробниками. У вашому блоці VirtualHost не повинно бути НЕ директиви DocumentRoot. Замість цього використовуйте блок "<Location />", щоб налаштувати параметри DAV svn для кореневого шляху.
nezroy

Я поставив у свою конфігурацію директиву Alias, наприклад, Alias svn /repositoriesа потім налаштував усе <Location /svn/ >. Проблема була точно так само, як у посиланні FAQ, хоча загадково, вона працювала ідеально протягом місяця, а потім зупинилася в середу вдень на час чаю. Якщо ваш сховище знаходиться на "/", то у вас буде перекриття з вашою директивою DocumentRoot.
Метт Конноллі

Це спрацювало чудово! Це була проблема DocumentRoot! +1
Feiticeir0


2

Перевірте цей веб-сайт: http://www.rkrishardy.com/2009/12/subversion-fix-svn-copy-causes-repository-moved-permanentl/

Можливо, псевдонім вказує на те саме місце, що і конфігурований - dav_svn.mod, а між apache та dav_svn існує стан перегонів під час доступу до репо.

Краще пояснити в наданій статті

У dav_svn.conf:

  <Location /svn>  #Alias we are talking about
  DAV svn

В apache_site.conf

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin webmaster@localhost
    ServerName svn.za11.pl

    #Alias /svn  "/mnt/nfs/svn/"  ###Comment out or change this alias
    DocumentRoot /mnt/nfs/svn/
    <Directory /mnt/nfs/svn/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
        AuthType Basic 
        AuthName "Subversion Repository"
        AuthUserFile /etc/apache2/dav_svn.passwd
        Require valid-user
    </Directory> 
... rest of the file

1
Посилання тут мертве, і ймовірної заміни немає.
sysadmin1138

//, Чи хотіли б оновити цю відповідь?
Натан Басанес

1

У мене встановлення vhost з моїм репо в svn.mydomain.com/sites/ моєму vhost був блок DocumentRoot і Location. Видалення кореня документа вирішило цю проблему.


1

Цю помилку я отримав, коли помилково помістив репо-файл під дерево html, яке обслуговує Apache, на моїй машині FC14 з установками на підривній основі та установкою Apache на основі RPM.

SVNParentPath (в /etc/httpd/conf.d/subversion.conf) повинен вказувати на каталог, що знаходиться поза DocumentRoot.

Я перемістив репо, і проблема пішла.

Сподіваюся, це допомагає.


1

Я знаю, що це старе, але я знайшов його в Google, тому що у мене був той самий випуск. Переконайтесь, що порт 7080 не заблокований ні брандмауером комп'ютера, ні сервером


0

Схоже, ви цього не робите svn checkout, а скоріше svn updateу наявному сховищі (?).

Якщо так, зробіть це:

svn switch --relocate http://svn.host.com/reponame


Ні, як ви бачите в повідомленні про помилку, яке я йому дав, написано "Команда: Оформити замовлення від ..." Я дійсно намагаюся отримати новий замовлення.
Барт С.

0

Переїхали назавжди? Ви можете щось на зразок HTTPFox чи щось таке і переконатися, що Apache видає правильний код статусу для вашого сховища (має бути 200/OK). Я вважаю, що код статусу 301відповідає URL-адресі, яка "перемістилася назавжди", і це виглядає як те, на що посилається клієнт svn.


Firebug та wget дають 200 ОК. Але, як я вже сказав, якщо переглядати його через браузер (серфінгу http://svn.server.com/repos), він чудово працює, я отримую "repos - Revision 0: /" і все. Проблема виникає лише тоді, коли я роблю замовлення.
Барт С.

0

Можливо, трохи запізнюємось у розмові, але я бачу це під час використання псевдоніму в налаштуваннях apache для вирішення трейлінгу '/': Alias ​​/ svn / path / to / svn /


0

Вам також потрібно переконатися, що жодна директива Alias ​​не відображає розташування svn repos. У мене це було недавно, коли я мав

Alias /svn /var/lib/svn
<Location /svn>
...
</Location>

де псевдонім та директива про розташування застосовуються до одного й того ж шляху.


0

Я просто мав подібну проблему не під час перевірки, а коли був зроблений COMMIT.

Причина? цю папку "obj \ Debug \ TempPE", з якоїсь дивної причини, папка "TempPE" неможливо ЗРОБИТИ її у сховище

Рішення? ... ЗРОБУЙТЕ по черзі всі інші папки проекту та видаліть це місце з SVN-сервера

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.