Copia de trabajo de Subversion más nueva que el servidor debido a la reversión de la copia de seguridad

Por lo tanto, mi administrador del servidor retrotrajo el servidor de subversión de una copia de seguridad. Mi copia de trabajo está en la revisión de 1534, pero el servidor se encuentra ahora en 1525, lo que da algunos problemas:Copia de trabajo de Subversion más nueva que el servidor debido a la reversión de la copia de seguridad

$ svn up 
svn: Revision 1534 not found

Por supuesto, siempre existe la opción de hacer una salida más limpia, pero ¿hay una manera más fácil ¿mi copia de trabajo local está sincronizada con el servidor?

Fuente

2009-11-07 rlovtang

¿Se han producido modificaciones por su parte? De lo contrario, es posible que tenga algunos problemas y deba revertir primero (¡asegúrese de hacer primero una copia de los archivos modificados!). Aunque no estoy 100% seguro. – RedGlyph

Se han confirmado, pero ahora se han perdido en el servidor debido a la reversión. Tengo los cambios en mi disco y también una copia adicional, listo para aplicar los cambios una vez más. – rlovtang

Bueno, dado que nada parece funcionar, probablemente deba volver a ejecutar todo:/Antes, si aún no lo ha hecho, podría hacer una última comprobación para ver si todo está realmente en el servidor hasta la revisión 1525 ('svn log -r HEAD ') como espera que sea ... – RedGlyph

Tienes que retirar de nuevo.

Su copia de trabajo está muerta.

Sus administradores realmente debe tratar de sincronizar su copia de seguridad en cada confirmación o almacenar las confirmaciones como vertederos a través de script gancho

Si está utilizando Windows/TortoiseSVN, por favor miran Martins answer a continuación.

Fuente

2009-11-07 21:06:14

Lo triste es que esto fue en realidad un tiempo de inactividad planificado, una actualización que no tuvo éxito. No recibí un aviso, y mantuvieron el servidor con vida por 2 horas más después de tomar la copia de seguridad .. :( – rlovtang

quizás sus administradores deberían aprender algunos svnbasics ... diríjalos a http://subtrain.tigris.org –

Buscar a la respuesta de @Martin, funcionó para mí y me ayudó a evitar una gran recarga. – moodboom

svn up -r HEAD

o especificar otra revisión específica debería funcionar.

Fuente

2009-11-07 15:10:33

Lo siento, ya lo intenté, mismo error mesage – rlovtang

¿Has probado con el número de revisión específico? 'svn up -r 1525'? – RedGlyph

Sí, el mismo error – rlovtang

No veo otra solución que no sea hacer una nueva compra y fusionar manualmente los cambios no confirmados en su nueva copia de trabajo. Básicamente, su copia de trabajo proviene de una realidad alternativa, una donde la actualización del servidor realmente funcionó, y no creo que Subversion tenga ninguna disposición para solucionar esto.

Fuente

2009-11-08 08:27:09 JesperE

Lo mismo nos sucedió hace unas semanas. Cambié el nombre de la carpeta de mi trono, revisé un baúl limpio y luego copié todos los archivos modificados desde la fecha del accidente y más allá a mi baúl para poder volver a comprometer los cambios.

Fuente

2009-11-13 11:53:05 kmacmahon

Sí, eso es lo que Terminé haciendo también. – rlovtang

Esto es lo que acabo de descubrir, siempre y cuando tenga una versión razonablemente actualizada de Tortoise SVN en su máquina y su copia de trabajo haya sido mantenida por esta versión (es decir, simplemente instale la última Tortoise SVN no funcionará).

Vaya al directorio de nivel superior y elimine la carpeta .svn; esto eliminará toda la información de SVN en caché local. Nota: la carpeta .svn solo aparece en la carpeta desprotegida de nivel superior y está oculta.

Luego, ingrese en la parte superior de su copia local existente. Tortoise volverá a versionar los archivos, dejando sus archivos modificados en paz. Luego podrá realizar cambios y actualizaciones sin ningún problema.

Fuente

2013-02-14 12:22:07 Martin

Esto hace que cada archivo existente se vuelva a "Versión", y funcionó maravillosamente para mí, ahorrándome literalmente horas de tiempo de pago. Nada más funcionó. Gracias @Martin – moodboom

Al menos para svn 1.8 svn update -r 1525 (según lo sugerido por Michael Hackner) funcionará y mantendrá intactos los archivos modificados localmente. Experimentó el problema similar hace unos minutos y lo resolvió con este comando.

que ser verificado lo que ocurrirá a los archivos cometidos entre 1525 y 1531.

Fuente

2016-03-16 11:08:41 al0

su copia de trabajo no está muerto. Sí, podría verificar nuevamente ... pero en mi caso eso es más de 20GB y tomaría mucho tiempo.

Todo lo que necesitaba para cuidar unos pocos archivos, que eran más nuevos en la copia de trabajo, que en el repositorio del servidor (también debido a la reversión).

Lo que puede hacer es hacer un PAGO DE SPARSE rápido (verifique solo un directorio) a la ubicación temporal. A continuación, desde esta ubicación de pago parcial, toma lo oculto.svn file (el historial de ese directorio) y colóquelo en su copia de trabajo problemática (que contiene un historial más reciente).

Esto no afectará a sus archivos de texto de origen, solo déles el historial anterior, pero coincidente con el repositorio. El texto de confirmación se pierde debido al tiempo de reversión, pero es fácil de volver a escribir.

Después de hacer eso, el svn funcionó bien y mostró todos los cambios que hice desde el tiempo de reversión. Por supuesto, debe COMETER esos cambios nuevamente.

Fuente

2017-02-01 22:11:00 EmbeddedGuy

Copia de trabajo de Subversion más nueva que el servidor debido a la reversión de la copia de seguridad

Respuesta

Cuestiones relacionadas