Este cliente es demasiado viejo para trabajar con la copia de trabajo

Question

En todas partes que voy a google recibo la misma respuesta a este problema, pero es la respuesta incorrecta para mí. Originalmente instalé Subversion 1.5.6 para Windows (ejecuto Windows Server 2008) en mi servidor e hice un repositorio para un proyecto. Luego utilicé una versión 1.6.X del cliente de Tortoise en mi computadora portátil para actualizar el proyecto. Todo estaba malísimo hasta que traté de usar un script de gancho post-commit (estoy actualizando las carpetas en wwwroot en commit para reflejar los cambios en una página web). Recibí un mensaje que decía: "Este cliente es demasiado viejo para trabajar con la copia de trabajo 'XXX'".

Así que desinstalé el cliente SVN en mi computadora portátil y eliminé el repositorio del servidor. Luego hice un nuevo repositorio en el servidor desde cero e instalé TortoiseSVN versión 1.5.6 pensando que si la versión del cliente es la misma que Subversion en el servidor, deberían funcionar bien. Después de descargar el repositorio en mi computadora portátil nuevamente y volver a instalar mi script de gancho recibo el mismo mensaje ...

Es bastante laborioso y perturbador tener que seguir borrando mis repositorios y reinstalando a mi cliente para encontrar los que cooperan a través de prueba y error. No veo ninguna razón (y no puedo encontrar ninguna en línea) sobre por qué el repositorio argumentaría si tanto TortoiseSVN como mi servidor Subversion son 1.5.6.

¿Hay alguien por ahí que pueda darnos una idea de por qué recibiría este mensaje? Quizás incluso alguien que podría decirme qué versión de TortoiseSVN necesito usar para que mi Server SVN 1.5.6 no se queje. Mi script de gancho funciona desde la línea de comando en mi servidor, así que sé que no es su culpa. Gracias por adelantado.

Answer 1

Resulta que mi versión de servidor de SVN era 1.5.6, pero el cliente de TortoiseSVN que había instalado en el servidor era la versión 1.6.3. Cuando revisaba mi copia de trabajo de wwwroot (o la actualicé con las opciones de clic derecho que me dio TortoiseSVN) y actualicé la versión de la copia de trabajo, el servidor SVN no pudo actualizarla porque era una versión más baja.

He descargado TortoiseSVN 1.5.6 del hipopótamo archivo y re-comprobado a cabo la copia de trabajo en el servidor y todo funcionaba muy bien!

Answer 2

Usted afirma que la causa de su problema no es la secuencia de comandos post-commit, pero mi corazonada es que es exactamente la raíz de sus problemas. Cuando se ejecuta el script post-commit, ¿cómo saca los archivos de su servidor Subversion para que pueda copiarlos en su servidor web? ¿No es eche un vistazo? Además, dices que todo funcionó bien hasta que instalaste el script de gancho post-commit.

He trabajado anteriormente en situaciones de instalación de SVN cliente/servidor en modo mixto, incluyendo TortoiseSVN como cliente y nunca he encontrado incompatibilidades, siempre y cuando los clientes que trabajan en el mismo repositorio tengan la misma versión.

¿Podría publicar los contenidos de su gancho post-commit para que podamos seguir elaborando?

Answer 3

Si pasa de 1.6 a 1.5, puede que tenga que retroceder. Nunca nos dice cómo mueve su repositorio, pero debe depender de cómo lo haga obtener una versión del repositorio en sí.

http://wiki.open.collab.net/wiki/Subversion_Client_FAQ#head-ed7f8e6b7f3265c74eaf7d49dcd4aab85bae2a12

Answer 4

ver en qué comando svn su script gancho post-commit se está ejecutando. Verifique que la versión de este comando coincida con la versión del último cliente SVN que toque su repositorio.

De forma predeterminada, cuando se utiliza una nueva versión de un cliente de subversión, se actualizará el repositorio a esa versión. Esto significa que, de repente, los clientes mayores simplemente dejan de funcionar.

Answer 5

Tuve el mismo error. Pero la causa fue que revisé el proyecto con un cliente svn 1.5 y mi complemento subclipse en eclipse fue la versión 1.4. Así que actualizando mi plugin de subclipse a la versión 1.6 hice el truco. por lo que el problema fue que el subclipse 1.4 no funciona con los proyectos que fueron probados con el cliente svn 1.5.

Espero que esto ayude a alguien.

Answer 6

En mi caso me trasladaron código eclipse desde un lugar a otro, entonces el problema comenzó. Para resolverlo, pago el formulario del proyecto svn repo. Luego, en el proyecto anterior, limpié todos los archivos svn. (simplemente busque .svn y elimine), luego copio el contenido en el proyecto que acaba de desproteger, mis cambios se hicieron visibles y mi proyecto está actualizado. Este método se puede aplicar para otros errores molestos. Espero que esto ayude a alguien