2009-11-11 14 views
17

Estoy intentando configurar Mercurial para el uso con un servidor de ventanas (freeSSHd) y el cliente (tanto en la línea de comandos y TortoiseHG). Estoy usando las versiones más recientes de todo ... todas descargadas en los últimos días. Utilizando la autenticación de clave pública, pude conectarme al servidor y puedo usar plink para ejecutar "hg version" y obtener una respuesta, pero cuando trato de clonar un repositorio desde el servidor ssh aparece el comando colgar. Correr con rendimientos -v:Mercurial sobre el cliente y el servidor SSH en Windows

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"" 

con nada más próxima. Al ejecutar el comando hg serve directamente en el servidor, se obtiene un servidor Mercurial aparentemente sensible, pero parece que los clientes no hacen más solicitudes.

Running "hg serve" en el directorio del repositorio y la clonación a través de HTTP funciona perfectamente.

¿Qué debería estar buscando para ayudar a depurar esto? ¿Hay algo que los clientes (hg y TortoiseHG) no envíen para continuar el flujo de solicitud?

Información adicional: Si cambio a un repositorio no válido en la máquina de destino, se muestra el error apropiado, por lo que parece que el hg remoto se está ejecutando y está evaluando correctamente la ruta.

Correr con --debug y los resultados --traceback en:

sending hello command 
sending between command 

Se cuelga aquí, hasta que 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! 

respuesta a Ryan: No parece haber ninguna Uso de la CPU o aumento del uso de la memoria en el servidor. Parece estar esperando que el cliente envíe una solicitud o algo similar.

19/11/2009: Más información: El problema está definitivamente en el lado freeSSHd/server de la ecuación. La conexión a bitbucket en ssh con el mismo conjunto de teclas funciona bien. Todavía estoy trabajando en esto.

+1

Pruebe a ejecutar 'hg clone' con la '--debug' y 'opciones' --traceback.Eso podría darte más pistas sobre la causa del problema. –

+0

Hrm, ¿hay actividad de la CPU en el proceso mercurial en el lado del cliente o del servidor? Cualquier tráfico de red en la interfaz? (Solo apuñalo en la oscuridad ...) –

+0

tuve los mismos problemas ... asegúrese de que la versión del servidor de mercurial esté actualizada. – nlucaroni

Respuesta

3

La solución que funcionó para mí fue desactivar la opción "Use nuevo motor de la consola", que está dentro de la pestaña SSH. Otra cosa es el camino. ssh: // ssh_user @ SSH_Server_Address: SSH_Port/Win_Drive_Letter:/Path_To_HG_Repository

Un ejemplo concreto:

ssh: //[email protected]: 5522/D:/repositorio/MyProyect/tronco

Actualmente uso MercurialHG no la CLI. Espero que esta ayuda

JQ

La solución realidad Me lo dio here

+0

Al no usar el "motor de la nueva consola", pude clonar un repositorio remoto, pero el proceso de hg aún se cuelga en el servidor de Windows, y solo cuando se cancela manualmente, el lado del cliente finaliza. –

+0

Lo mismo para tirar/empujar. Si trato de terminar el lado del cliente con Ctrl-C, entonces no pasa nada, pero después de matar al lado del servidor de proceso hg, la salida del lado del cliente contiene: Exception KeyboardInterrupt: KeyboardInterrupt() en > ignorado. A través de TortoiseHG es lo mismo, TortoisePlink se bloquea, pero si este proceso se cancela, el proceso de hg del servidor también se extingue. –

+0

El mismo problema se describe en http://selenic.com/pipermail/mercurial/2008-July/020382.html –

0

Quizás es el caso que 'hg' no está en el camino. Puede ver desde la línea de comando que se invoca que 'hg' se está ejecutando como 'hg', lo que significa que debe estar en la ruta del servidor. Intente utilizar la opción --remotecmd para clonar y dar la ruta completa al archivo ejecutable hg en el servidor (buena suerte haciendo que las ventanas hagan las citas correctas).

Es posible que su prueba de plink hg version funcione porque se lanzó como un intérprete de comandos interactivo que obtiene una ruta diferente, al menos eso con frecuencia obstaculiza a las personas en Unix.

+0

Al cambiar a una ruta de depósito no válida, puedo obtener un error, así que estoy bastante seguro de que hg se está invocando correctamente y está en la ruta. Arriba también he proporcionado resultados de --debug y --traceback. –

+0

Sí, suena bien. Eliminaré esta respuesta una vez que alguien lo descubra. –

2

Obtuve los mismos síntomas en este momento, aunque hg fue un poco más útil después de Ctrl + C - al parecer, Plink estaba esperando que dijera y/n para "guardar el servidor en la memoria caché". Desafortunadamente hg no podía pasar mi s/n de forma interactiva (ni decirme que plink impresa algo importante ...)

Solución:

  1. plink para el anfitrión de una vez y guardar la información del servidor para almacenar en caché
  2. agregue -batch a la línea de comando de plink para que la próxima vez que esto suceda aborte.

También agregue mi clave al concurso así que no necesito ingresar la contraseña en ningún otro lado.

Ejemplo completo del archivo .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 
+0

Para mí, -batch no resolvió el problema. Me las había arreglado para obtener los certificados en el caché previamente. Necesito encontrar más tiempo para profundizar en esto, pero parece que hg simplemente no está emitiendo los comandos del cliente para comenzar a trabajar. –

+0

La mejor respuesta. ¡Gracias! – mpen

1

Otra opción sería la de tratar las versiones de Cygwin de Hg y ssh. Puede registrar problemas de SSH en esa versión con la opción -e; por ejemplo, el clon hg -e 'ssh -vvv' ssh: // que @ servidor/repo ...

1

me encontré con este mismo problema. No estoy seguro de cómo se relaciona con el tuyo, pero esto es lo que funcionó para mí. Primero, explicaré mi configuración. Tengo un repositorio en mi sitio en vivo mysite.com Tengo un repositorio local en mi máquina local en una carpeta mysite.com Tengo otros repositorios, así que agrego configuraciones [ui] al archivo /.hg/.hgrc en cada carpeta de repositorio en mi máquina local en lugar del archivo Mercurial.ini.

En primer lugar, si ya ha conectado a través de la masilla, guardar la sesión porque Plink puede utilizar sesiones almacenadas. Usa el concurso y agrega tu clave. Pruebe a ejecutar plink desde la línea de comandos para conectarse a través de la sesión almacenada. Por ejemplo, guardé mi sesión como "mysite" en 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;[email protected]:~[[email protected] ~]$ 

Si eso funciona, pruebe lo siguiente en su archivo .hgrc

[path] 
default = ssh://[email protected] 
[ui] 
username = RB <[email protected]> 
ssh=plink.exe -ssh -i mysite 

Plink se encuentra en mi camino, y desde la sesión mysite ya se almacena en la masilla, que sabe lo que debe buscar para.

yo estaba tratando de hacer un tirón, así que estaba poniendo a prueba usando:

hg pull --debug --traceback 

Espero que ayude.

Edit: Lo siento, vio demasiado tarde que estaba utilizando TortoiseHg en lugar de masilla. Espero que ayude de todos modos.

1

En mi caso, yo era capaz de conectar con el servidor una vez, pero la segunda vez que fracasaron.

que tienen la misma configuración y funcionó perfectamente ... pero sólo una vez. No hay nada en mis sesiones almacenadas.

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