Checkout SVN repository desde una networking

Hice una pregunta similar antes ¿Cómo actualizar TortoiseSVN en la networking? . En ese momento estaba usando una copy VM del server, y la solución que enlisté funcionó. Esta vez estoy usando el server real y tengo problemas para salir de mi repository.

Unable to open an ra_local session to URL Unable to open repository 'file://REMOTE-PC/repositories/MyApps/trunk/App1' Can't open file '\\REMOTE-PC\repositories\MyApps\trunk\App1\format': Logon failure: unknown user name or bad password. 

Mis preguntas son

  1. ¿Necesito un permiso especial en la carpeta del server para poder realizar el check-in con éxito en el repository?

  2. La documentation aquí señala qué protocolo usar ¿dónde? Estaba usando esto antes en VM que funcionó

    file: // REMOTE-PC / repositories / MyApps / trunk / App1

¿Qué debería estar usando?

 +------------+--------------------------------------------------------------+ | file:/// | Direct repository access (on local disk) | | http:// | Access via WebDAV protocol to Subversion-aware Apache server | | https:// | Same as http://, but with SSL encryption. | | svn:// | Access via custom protocol to an svnserve server | | svn+ssh:// | Same as svn://, but through an SSH tunnel. | +------------+--------------------------------------------------------------+ 

¿Qué funcionó antes y ahora no funciona? Por favor dirija ambas preguntas.

También quiero mencionar: si quiero acceder a mi PC (donde están los repositorys) desde el server (estoy usando el escritorio remoto), tengo que ingresar el nombre de usuario y la contraseña. ¿Tengo que proporcionar estos en el command SVN?

Nunca debe usar el protocolo file:// . Nunca nunca nunca. Bueno, hay ocasiones en que se puede usar, pero solo debería serlo si todo lo siguiente es verdadero:

  • Usted es el único que usa el repository.
  • El repository está sentado en su sistema.
  • Estás probando a Subversion.

Si su repository se encuentra en un sistema remoto. No use el file:// . Si se trata de un repository público, no use file:// . El process del server svnserve Subversion es extremadamente fácil de configurar y usar. Además, es rápido y evita todos los problemas y errores asociados con el acceso directo al repository. De hecho, en mi repository privado que se encuentra en mi sistema, uso svnserve .


Hay al less una docena de errores que podrían popup para causar los problemas que señala. Hay permissions necesarios para el server, en el sistema Windows moderno, podría haber problemas de UAC incluso si ha iniciado session como administrador. Simplemente está pidiendo problemas.

Eche un vistazo a la documentation para configurar svnserve . El mayor problema con el que se encontrará es asegurarse de que su departamento de TI no esté bloqueando el puerto 3690.

Ejecute el process svnserve en el server remoto y asegúrese de que el process del server tenga la propiedad completa y todos los permissions en todos los files del repository.

Hay un par de inconvenientes sobre el process svnserve que no permite que se ejecute de la caja:

  • Edite el file conf/svnserve.conf : este file es bastante bueno por defecto. Sin embargo, el file de contraseña pnetworkingeterminado está comentado. Elimina el # que ves al frente de la línea password-db = passed . No estoy seguro de por qué esto no es el pnetworkingeterminado. También puede establecer el nombre del realm mientras lo hace. Eso no es necesario.

  • Edite el file passwd : debe configurar el nombre de usuario y la contraseña para cada usuario. Solo sigue el ejemplo.

Y, luego ejecuta svnserve y ahora puedes acceder a tu repository a través de:

 $ svn ls svn://REMOTE-PC/MyApps/trunk/App1 

Esto es fácil de hacer (todo se puede configurar en minutos) y eliminará todos sus problemas.

Con Subversion, sus bibliotecas tienen requisitos estrictos sobre los files que se manipulan para almacenar "el repository". Servicios SMB / Windows shares / Samba no cumple con esos requisitos.

Nunca debe ocultar la networking de subversión utilizando el protocolo file:// en un file:// compartido de networking. Esto significa que las fallas y fallas de la networking no desencadenan la conciencia de subversión de que un cambio podría no almacenarse adecuadamente. Dependiendo del cambio y las circunstancias, esto puede tener efectos muy negativos en su repository.

Si está utilizando un repository remoto, use uno de los protocolos de networking consciente. Tienen el código adecuado para detectar y capturar las interrupciones de la networking y no se confundirán con el error de informar que algo se guardó en el repository.

Compruebe los permissions de lectura / escritura en esta ruta:

 \\REMOTE-PC\repositories\MyApps\trunk\App1