Subversion игнорирует опции "--password" и "--username"

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

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

# $ svn update --username 'user2' --password 'password'
# [email protected] password:

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

# $ svn --version --quiet
# 1.3.2

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

Я запускаю svn 1.3.2 (r19776) на Fedora Core 5 (Bordeaux).

Вот список моих переменных среды (с секретной информацией X'ed out). Ни один из них, похоже, не относится к 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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Host server.hostname
  User username

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

Посмотрите на свой локальный репозиторий 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 как обычно.

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

Ответ 7

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

svn switch --relocate \
    svn+ssh://[email protected]/path/to/repo \
    svn+ssh://[email protected]/path/to/repo

где svn+ssh://[email protected]/path/to/repo можно найти в строке вывода URL: команды svn info. Эта команда попросила меня ввести пароль newuser.

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