Разрешаване на грешка в името на хоста при достъп до Subversion

Получавам грешка, когато се опитвам да направя следните команди в Subversion: update, commit, log, list, blame и т.н.
Въпреки това, diff и info работят.

Грешката е следната при използване на десктоп клиент, напр. CollabNet, TortoiseSVN, Intellij, AnkhSVN на Visual Studio: "http://xxx01/comm/JavaService/trunk/: Името на хоста не може да бъде преобразувано `http://xxx01/comm': Исканото име е валидно и е намерено в базата данни, но тя няма правилните асоциирани данни, за които се разрешава."

Това се случва само на моя лаптоп (не на колеги) и започна да се случва едва тази седмица, след като администраторите промениха паролата за акаунта, който Subversion използва за удостоверяване. Грешката не възниква, когато използвам отдалечен работен плот към друга машина или влизам в subversion през мрежата.

Благодаря предварително за всяка помощ при разрешаването на този проблем.


hostname svn resolve
person David    schedule 26.02.2010    source източник
comment
Какъв URL адрес показва информацията за subversion - не съм сигурен как го правите във вашите клиенти за subversion, но на командния ред е 'svn info'   -  person Martin    schedule 26.02.2010
comment
Не можахте да разрешите името на хоста? Предполагам, че нещо не е наред с настройката на вашия DNS сървър.   -  person N 1.1    schedule 26.02.2010
comment
Не е свързано с програмиране? мигрирайте към superuser.com   -  person N 1.1    schedule 26.02.2010
comment
Защо не се свържете чрез IP адрес? Това няма да се промени и винаги трябва да се разрешава.   -  person Ariel Bold    schedule 02.03.2011

Отговори (5)


arrow_upward
7
arrow_downward

Изглежда, че настройките на вашия прокси сървър трябва да се актуализират. Subversion съхранява всички тези настройки в текстов файл с име "сървъри" (без разширение).

В Windows този файл се намира в %APPDATA%/Subversion/ (напр. C:\Documents and Settings\YourUserName\Application Data\Subversion).

1) Отворете „сървъри“ и се уверете, че всички данни за вашия прокси сървър са правилни. Трябва да има указания във файла как да промените паролата си, но това ще включва промяна на тези редове:

[GLOBAL]:
http-proxy-host = proxyserver.example.com
http-proxy-port = 80
http-proxy-username = yourusername
http-proxy-password = yourpassword

2) Освен това понякога Tortoise SVN поддържа активна неправилна настройка на прокси сървъра. Ако имате инсталирана Tortoise, независимо дали я използвате или не (особено ако използвате Subclipse): отворете GUI за настройки на Tortoise, отидете до „Мрежа“ и се уверете, че настройките са правилни под „Активиране на прокси сървър“.

person Community    schedule 31.12.2010
comment
Само аз ли съм, или това е абсурдно несигурен начин за съхраняване на данни за удостоверяване на SVN? - person Kehlan Krumme; 07.09.2013

arrow_upward
5
arrow_downward

Изглежда, че имате домейн по подразбиране в настройките на вашия работен плот, сравнете резултата от

nslookup xxx01 от вашия настолен компютър и лаптоп. Можете също така да използвате напълно квалифицирано име като xxx01.acme.com във вашия SVN URL адрес.

person stacker    schedule 26.02.2010
comment
snv информацията показва правилния URL адрес на корена на хранилището: xxx01/comm nslookup xxx01 показва една и съща информация както на лаптоп, така и на отдалечен работен плот и разрешава към правилния псевдоним xxx01.acme.com. Освен това използването на напълно квалифицирано име или IP адрес в url не влияе на резултата. - person David; 26.02.2010
comment
@David Тъй като използвате http (порт 80) и предполагам, че можете да сърфирате в мрежата. Нямам по-добра идея от деактивирането на защитната стена. съжалявам - person stacker; 26.02.2010

arrow_upward
0
arrow_downward

От кодове за грешки на Windows Sockets:

Исканото име е валидно и е намерено в базата данни, но няма правилните свързани данни, за които се разрешава, напр. връща се MX запис, но не и A запис - което показва, че самият хост съществува, но не е директно достъпен.

Понякога след някои промени в имената на хостовете са необходими няколко рестартирания (или няколко часа изчакване), докато тези промени се използват напълно (поради кеширане).

Или може да има намеса от защитна стена/прокси/вирусен скенер.

person Stefan    schedule 26.02.2010

arrow_upward
0
arrow_downward

Опитах всичко, за да разреша този проблем. Намерих злонамерен софтуер на моята машина повреден файл, но нищо от това не реши проблема. В крайна сметка записах машината, преинсталирах TortoiseSVN ... и готово! Оправи проблема ;-)

person David    schedule 17.03.2010

arrow_upward
0
arrow_downward

Наскоро се сблъсках с този проблем, вероятно защото някои .svn файлове бяха повредени. Създадох нова папка и позволих на tortoisesvn да провери цялата версия. Работи.

person sambsp    schedule 29.08.2012