Subversion игнорирует параметры "--password" и "--username"

Question

Когда я пытаюсь выполнить любую команду svn и указать параметры --username и / или --password, он в любом случае запрашивает мой пароль и всегда пытается использовать моего текущего пользователя вместо того, который указан в --username. Ни --no-auth-cache, ни --non-interactive не имеют никакого влияния на это. Это проблема, потому что я пытаюсь вызывать команды svn из скрипта, и я не могу заставить его показать приглашение.

Например, вошли как user1:

# $ svn update --username 'user2' --password 'password'
# user1@domain.com's password: 

Другие параметры работают правильно:

# $ svn --version --quiet
# 1.3.2

Почему это подсказывает мне?
И почему он запрашивает пароль user1 вместо user2?
Я на 99% уверен, что все мои разрешения установлены правильно. Есть ли какая-либо опция конфигурации для SVN, которая отключает пароли командной строки?
Или это что-то совсем другое?

Я использую SVN 1.3.2 (r19776) на Fedora Core 5 (Бордо).

---

Вот список моих переменных окружения (с удаленной конфиденциальной информацией). Кажется, ни один из них не относится к SVN:

# HOSTNAME=XXXXXX
# TERM=xterm
# SHELL=/bin/sh
# HISTSIZE=1000
# KDE_NO_IPV6=1
# SSH_CLIENT=XXX.XXX.XXX.XXX XXXXX XX
# QTDIR=/usr/lib/qt-3.3
# QTINC=/usr/lib/qt-3.3/include
# SSH_TTY=/dev/pts/2
# USER=XXXXXX
# LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:
# KDEDIR=/usr
# MAIL=/var/spool/mail/XXXXXX
# PATH=/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin
# INPUTRC=/etc/inputrc
# PWD=/home/users/XXXXXX/my_repository
# KDE_IS_PRELINKED=1
# LANG=en_US.UTF-8
# SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
# SHLVL=1
# HOME=/home/users/XXXXXX
# LOGNAME=XXXXXX
# QTLIB=/usr/lib/qt-3.3/lib
# CVS_RSH=ssh
# SSH_CONNECTION=69.202.73.122 60998 216.7.19.47 22
# LESSOPEN=|/usr/bin/lesspipe.sh %s
# G_BROKEN_FILENAMES=1
# _=/bin/env
# OLDPWD=/home/users/XXXXXX

Answer 1

У вас действительно есть одинарные кавычки в вашей команде? Я не думаю, что они необходимы. Кроме того, я думаю, что вам также нужно --no-auth-cache и --non-interactive

Вот что я использую (без одинарных кавычек)

--non-interactive --no-auth-cache --username XXXX --password YYYY

Для получения дополнительной информации см. Кэширование учетных данных клиента в svnbook .

Answer 2

Приглашение, которое вы получаете, не похоже на Subversion, запрашивающую у вас пароль, похоже, что ssh запрашивает пароль. Поэтому я предполагаю, что вы извлекли svn + ssh: // checkout, а не svn: // или http: // или https: // checkout.

IIRC все опции, которые вы пытаетесь использовать, работают только для проверок svn / http / https. Можете ли вы запустить svn info, чтобы подтвердить, какой репозиторий вы используете?

Если вы используете ssh, вы должны настроить аутентификацию на основе ключей, чтобы ваши скрипты работали без запроса пароля.

Answer 3

У меня возникла та же проблема, и я решил ее, настроив файл ~ / .ssh / config для явного использования правильного имени пользователя (то есть того, которое вы используете для входа на сервер, а не на локальный компьютер). Так, например:

Host server.hostname
  User username

Я нашел этот пост полезным: http://www.highlevelbits.com/2007/04/svn-over-ssh-prompts-for-wrong-username.html

Answer 4

У меня была похожая проблема, я хотел использовать другое имя пользователя для хранилища svn + ssh. В итоге я использовал svn relocate (как описано в в этом ответе . В моем случае я использую SVN 1.6.11 и сделал следующее:

svn switch --relocate \
    svn+ssh://olduser@svnserver/path/to/repo \
    svn+ssh://newuser@svnserver/path/to/repo

, где svn+ssh://olduser@svnserver/path/to/repo можно найти в строковом выводе URL: команды svn info. Эта команда попросила у меня пароль newuser.

Обратите внимание, что это изменение является постоянным, то есть, если вы хотите только временно переключиться на новое имя пользователя с помощью этого метода, вам придется снова вводить аналогичную команду после svn update и т. Д.

Answer 5

Посмотрите на локальный репозиторий svn и загляните в каталог .svn. есть файл: записи просматривают их, и вы увидите строки, начинающиеся с: SVN + SSH: //

это ваша первая конфигурация, созданная svn checkout 'repo_source' или svn co 'repo_source'

Если вы хотите изменить это, лучше всего полностью обновить этот репозиторий. обновите / зафиксируйте то, что вы должны для сохранения работы. затем полностью удалите каталог и последний шаг - это создать svn co / checkout 'URI-for-main-repo' [опционально локальный каталог для хранилища]

Вы должны выбрать способ подключения для файла репо: // svn + ssh: // http: // https: // или другой описано в документации.

после этого вы используете svn update / commit как обычно.

эта тема выглядит не по теме. лучше переходить на страницы суперпользователя.

Answer 6

Проблема заключалась в том, что рабочая копия была проверена через svn + ssh (спасибо, Томас). Вместо настройки ключей ssh, как было предложено, я просто извлек новую рабочую копию, используя svn: //domain.com/path/to/repo, а не svn + ssh: //domain.com/path/to/repo. Поскольку эта рабочая копия находится на том же компьютере, что и сам репозиторий, я не пропускаю ничего, и теперь я могу использовать опции --password и --username безвозмездно. Кажется очевидным теперь, когда я думаю об этом.

Answer 7

Лучшее, что я могу вам дать - это "работает для меня" в SVN 1.5. Вы можете попытаться добавить --no-auth-cache к вашему svn update, чтобы узнать, позволяет ли это вам переопределить более легко.

Если вы хотите навсегда переключиться с user2 на user1, перейдите в ~ / .subversion / auth / on * nix и удалите файл кэша аутентификации для domain.com (скорее всего, в ~ / .subversion / auth / svn.simple / - просто прочитайте их, и вы найдете тот, который вы хотите оставить). Хотя возможно обновить текущий кеш аутентификации, вы также должны обновить токены длины. Проще просто получить запрос снова при следующем обновлении.