Mercurial через ssh клиент и сервер в Windows

Question

Я пытаюсь настроить Mercurial для использования как с сервером Windows (freeSSHd), так и с клиентом (как с командной строкой, так и с TortoiseHG). Я использую самые последние версии всего ... все загружено за последние несколько дней. Используя аутентификацию с открытым ключом, я смог подключиться к серверу, и я могу использовать plink для выполнения «hg version» и получения ответа, но когда я пытаюсь клонировать репозиторий с сервера ssh, появляется команда похмелья. Запуск с -v выходами:

hg -v clone ssh://<username>@<server>//hg/repositoryA testRepositoryA
running "plink.exe -i "<path to private key file>" <username>@<server> "hg -R /hg/repositoryA serve --stdio""

ни с чем более готовым. Выполнение команды hg serve непосредственно на сервере приводит к появлению, по-видимому, отзывчивого сервера Mercurial, но, похоже, клиенты больше не выполняют никаких запросов.

Запуск "hg serve" в каталоге репозитория и клонирование по http работает отлично.

Что я должен искать, чтобы помочь отладить это? Есть ли что-то, что клиенты (hg и TortoiseHG) не отправляют, чтобы продолжить поток запросов?

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

Работа с --debug и --traceback приводит к:

sending hello command
sending between command

Здесь висит, пока я не нажму CTRL-C

Traceback (most recent call last):
  File "mercurial\dispatch.pyo", line 46, in _runcatch
  File "mercurial\dispatch.pyo", line 452, in _dispatch
  File "mercurial\dispatch.pyo", line 320, in runcommand
  File "mercurial\dispatch.pyo", line 504, in _runcommand
  File "mercurial\dispatch.pyo", line 457, in checkargs
  File "mercurial\dispatch.pyo", line 451, in <lambda>
  File "mercurial\util.pyo", line 402, in check
  File "mercurial\commands.pyo", line 636, in clone
  File "mercurial\hg.pyo", line 187, in clone
  File "mercurial\hg.pyo", line 63, in repository
  File "mercurial\sshrepo.pyo", line 51, in __init__
  File "mercurial\sshrepo.pyo", line 73, in validate_repo
KeyboardInterrupt
interrupted!

Реагирование на Райана. Похоже, что загрузка процессора или увеличение использования памяти на сервере отсутствуют. Похоже, он ждет, пока клиент отправит запрос или что-то подобное.

11/19/2009: дополнительная информация: Проблема определенно в стороне freeSSHd / server уравнения. Подключение к bitbucket через ssh с тем же набором ключей работает нормально. Все еще работаем над этим.

Answer 1

Решением, которое работало для меня, было отключение опции «Использовать новый консольный движок», которая находится на вкладке SSH. Другое дело путь. SSH: // ssh_user @ SSH_Server_Address: SSH_Port / Win_Drive_Letter: / Path_To_HG_Repository

Конкретный пример:

SSH: //programmer@192.168.1.150: 5522 / D: / Repository / MyProyect / багажник

В настоящее время я использую MercurialHG, а не CLI. Я надеюсь, что это поможет

JQ

Решение на самом деле я получил от здесь

Answer 2

У меня появились те же симптомы только сейчас, хотя hg был немного более полезен после Ctrl + C - очевидно, plink ждал, когда я скажу y / n "сохранить сервер в кэш". К сожалению, hg не смог передать мои данные в интерактивном режиме (и не сказать мне, что plink напечатал что-то важное ...)

Решение:

1. подключитесь к хосту один раз и сохраните информацию о сервере в кеш
2. добавьте -batch в командную строку plink, чтобы в следующий раз это прервалось.

Я также добавляю свой ключ к конкурсу, чтобы мне больше не приходилось вводить пароль.

Полный пример файла .hgrc (Win + R, notepad %USERPROFILE%\.hgrc):

[ui]
ssh=C:\Path\To\plink.exe -C -batch -ssh -i C:\Path\To\My\putty-private-ssh-key.ppk

Answer 3

В моем случае мне удалось подключиться к серверу один раз, но во второй раз это не удалось.

У меня такая же настройка, и она отлично работала ... но только один раз. В моих сохраненных сеансах ничего нет.

[ui]
ssh=C:\Path\To\plink.exe -C -batch -ssh -i C:\Path\To\My\putty-private-ssh-key.ppk

Answer 4

Я столкнулся с этой же проблемой. Не уверен, как это относится к твоему, но это то, что сработало для меня. Сначала я объясню мои настройки. У меня есть репозиторий на моем живом сайте mysite.com У меня есть локальный репозиторий на моей локальной машине в папке mysite.com У меня есть другие репозитории, поэтому я добавляю настройки [ui] в файл /.hg/.hgrc в каждой папке репозитория на моем локальном компьютере вместо файла Mercurial.ini.

Во-первых, если вы уже подключились через Putty, сохраните сеанс, потому что Plink может использовать сохраненные сеансы. Используйте Pageant и добавьте свой ключ. Попробуйте запустить plink из командной строки для подключения с использованием сохраненного сеанса. Например, я сохранил свой сеанс как «mysite» в Putty.

C:\>plink mysite
    Using username "mysite".
    Last login: Fri Feb 26 21:16:05 2010 from ca-xxx-xx-x-xxx.sta.host.net
    ←]0;mysite@server:~[mysite@server ~]$

Если это работает, попробуйте следующее в вашем файле .hgrc

[path]
default = ssh://mysite@myhost
[ui]
username = RB <admin@mysite.com>
ssh=plink.exe -ssh -i mysite

Plink установлен в моем PATH, и поскольку сеанс mysite уже был сохранен в Putty, он знает, что искать.

Я пытался сделать тягу, поэтому я тестировал, используя:

hg pull --debug --traceback

Надеюсь, это поможет.

Редактировать: Извините, слишком поздно вы увидели, что вы используете tortoiseHG вместо замазки Надеюсь, это все равно поможет.

Answer 5

Другой вариант - попробовать версии Cygwin для hg и ssh. Вы можете регистрировать проблемы SSH в этой версии с опцией -e; например, hg clone -e 'ssh -vvv' ssh: //you@server/repo...

Answer 6

Возможно, дело в том, что 'hg' не на пути. Вы можете увидеть из вызываемой командной строки, что «hg» запускается как «hg», что означает, что он должен находиться на пути к серверу. Попробуйте использовать опцию --remotecmd для клонирования, чтобы указать полный путь к исполняемому файлу hg на сервере (удачи в правильном цитировании окон).

Возможно, ваш тест plink hg version работает, потому что он запускается как интерактивная оболочка, которая получает другой путь - по крайней мере, который часто блокирует людей в Unix.