reparación SVN suma de comprobación

Question

estoy usando Subclipse en Flex Builder 3, y recientemente recibió este error al intentar cometer:

svn: Checksum mismatch for '/Users/redacted/Documents/Flex Builder 3/path/to/my/file.mxml'; expected: 'f8cb275de72776657406154dd3c10348', actual: 'null'

trabajé alrededor de él:

1. cometiendo toda la otros archivos cambiados, omitiendo el problemático.
2. copiar el contenido del archivo de trabajo de una ventana TextMate
3. Eliminación de mi proyecto en FlexBuilder/Eclipse
4. Comprobación de mi proyecto fuera fresca desde SVN
5. copiar el texto del archivo de problemas de espalda desde la ventana de TextMate
6. Commitir los cambios.

Funcionó, pero no puedo evitar pensar que hay una mejor manera. ¿Qué está sucediendo exactamente para causar el error svn: suma de comprobación, y cuál es la mejor solución?

Quizás más importante: ¿es este un síntoma de un problema mayor?

Answer 1

El archivo en el directorio .svn que realiza un seguimiento de lo que ha comprobado, cuándo, qué revisión y de dónde, se ha corrompido de alguna manera, para ese archivo en particular.

Esto no es más peligroso o crítico que el problema de los archivos extraña normal, y puede ser debido a diversos problemas, como un programa de subversión morir mediados de cambio, el poder-interrupción, etc.

A menos que suceda más me no sacaría mucho provecho de eso.

Se puede fijar al hacer lo que hizo, haga una copia de su trabajo-archivos, echa un vistazo a una copia nueva, y añadir los archivos modificados de nuevo.

Tenga en cuenta que esto podría causar problemas si usted tiene un proyecto ocupado donde normalmente debería fusionarse en cambios.

Por ejemplo, usted y un colega comprueban una copia nueva y comienzan a trabajar en el mismo archivo. En algún momento, su colega comprueba sus modificaciones. Cuando intenta hacer lo mismo, obtiene el problema de suma de comprobación que tiene. Si ahora hace copias de sus archivos modificados, haga un nuevo checkout, entonces la subversión perderá la pista de cómo deberían fusionarse sus cambios.

Si no obtuvo el problema en este caso, cuando estuvo cerca Para registrar sus modificaciones, primero deberá actualizar su copia de trabajo y posiblemente manejar un conflicto con su archivo.

Sin embargo, si haces un checkout nuevo, completa con los cambios de tus colegas, ahora parece que eliminaste los cambios y los sustituiste por los tuyos. Sin conflictos y sin indicaciones de subversión de que algo anda mal.

Answer 2

De vez en cuando obtengo cosas similares, generalmente con archivos que nadie ha estado cerca en semanas. En general, si usted sabe que no ha estado trabajando en el directorio en cuestión, sólo puede borrar el directorio con el problema y ejecutar

svn update 

volver a crearlo.

Si tiene cambios en vivo en el directorio, entonces como lassevk y usted mismo sugirió, se requiere un enfoque más cuidadoso.

En general, diría que es una buena idea no dejar los archivos editados sin confirmar y mantener ordenada la copia de trabajo; no agregue un montón de archivos adicionales en la copia de trabajo que no va a utilizar. Comience con regularidad, y luego, si la copia de trabajo se pone de punta, puede simplemente eliminar todo y volver a empezar sin preocuparse por lo que puede o no puede perder, y sin el dolor de tratar de averiguar qué archivos guardar.

Answer 3

Justo hoy, me las arreglé para recuperarme de este error revisando una copia del directorio corrupto a/tmp y reemplazando los archivos en .svn/text-base con los que acabo de usar. Escribí el procedimiento con algún detalle here on my blog. Me interesaría saber de los usuarios de SVN más experimentados cuáles son las ventajas y desventajas de cada enfoque.

Answer 4

SVN mantiene copias prístinas de todos los archivos que ha guardado enterrados en los directorios .svn. Esto se llama base de texto. Esto permite diferencias rápidas y revierte. Durante varias operaciones, SVN hará sumas de verificación en estos archivos de base de datos para detectar problemas de corrupción de archivos.

En general, una discrepancia en la suma de verificación de SVN significa que un archivo que no debería haber sido modificado se modificó de alguna manera. Qué significa eso?

1. disco corrupción (mal disco duro o cable IDE)
2. RAM defectuosa
3. enlace Malo red
4. algún tipo de proceso de fondo alterado un archivo detrás de la espalda (malware)

Todos de estos son malos

SIN EMBARGO, creo que su problema es diferente. Mira el mensaje de error. Tenga en cuenta que esperaba algunos valores hash MD5, pero en su lugar obtuvo 'nulo'. Si esto fuera un simple problema de corrupción de archivos, esperaría que tuvieras dos hash MD5 diferentes para el esperado/conseguido. El hecho de que tengas un 'nulo' implica que algo más está mal.

Tengo dos teorías:

1. Bug en SVN.
2. Algo tenía un bloqueo exclusivo en el archivo, y el MD5 no podría suceder.

En el caso del n. ° 1, intente actualizar a la última versión de SVN. Tal vez también publique esto en la lista de correo svn-devel (http://svn.haxx.se), para que los desarrolladores puedan verlo.

En el caso del n. ° 2, verifique si algo tiene el archivo bloqueado. Puede descargar una copia de Process Explorer para verificar. Tenga en cuenta que probablemente quiera ver quién tiene un bloqueo en el archivo con base de texto, no en el archivo real que intentaba comprometer.

Answer 5

También hay una causa más simple para esto que solo errores o daños en el disco, etc. Creo que la causa más probable es que alguien escriba un reemplazo de texto recursivo en la copia de trabajo, sin excluir los archivos .svn.
Esto significa que las copias prístinas de los archivos (básicamente la versión BASE de los archivos, que está almacenada dentro del área administrativa .svn) se modifican y eso invalida la suma MD5.

@Andrew Hedges: eso también explica por qué su solución corrige esto.

Answer 6

intento: svn up file.c --force

Esto funcionó para mí sin tener que hacer nada extra

Answer 7

Si este tema, nuestra dev VM son todos * nix nuestras estaciones de trabajo Win32. algunos tontos crearon archivos del mismo nombre (caso diferente) en la casilla * nix , de repente, las salidas en Win32 explotaron ... porque win no sabe cuál de los 2 archivos del mismo nombre a MD5 en contra, las cajas en * nix estaban bien ... dejándonos rascar nuestras cabezas por un poco

Pude actualizar el repositorio en el cuadro de ganancias copiando las carpetas ".svn" de a * nix box con una buena copia de trabajo. sin embargo, hay que ver si el repositorio se puede limpiar hasta el punto en que podemos hacer una extracción completa de nuevo

Answer 8

Otro, posiblemente aún más aterrador, solución para los conflictos de suma de comprobación que he encontrado es el siguiente:

advertencia: Hacer ¡Asegúrese de que su copia local sea la versión más conocida, Y que cualquier otra persona en su proyecto sepa lo que está haciendo! (en caso de que esto ya no fuera obvio).

si sabe que su copia local del archivo es "la buena", puede eliminar directamente el archivo del servidor SVN y luego forzar la confirmación de su copia local.

sintaxis de eliminación directa:

svn delete -m "deleting corrupted file XXXX" 
svn+ssh://username@svnserver/path/to/XXXX 

buena suerte!

J

Answer 9

Así es como lo ha solucionado el problema - v simple, pero según jsh anteriormente, necesita estar seguro de su copia es la mejor.

simplemente

1. hacer una copia de todos los archivos de problemas, en la misma carpeta.
2. borre los viejos con svn rm
3. commit.
4. luego cambie el nombre de las copias a los nombres de los archivos originales.
5. cometer nuevamente.

sospechoso esto probablemente mata todo tipo de historial de revisiones en ese archivo, por lo que es una manera bastante feo de hacerlo ...

Answer 10

que he observado una gran cantidad de soluciones de parcheo .svn/entradas archivo a la caja nueva.

Puede ser una nueva forma (gracias a mi colega):

- go to work directory where recorder/expected checksum issue occured 
- call "svn diff" and make sure that there isnt any local modifications 
- cd .. 
- remove trouble file's directory with "rm -rf" 
- issue "svn up" command, svn client will restore new fresh files copies 

Answer 11

Matt, no hay manera más fácil de lo que usted describe - la modificación de la suma de comprobación en el archivo de .svn/entradas. He aquí la descripción completa: http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

Answer 12

Otra forma fácil ....

1. actualización de su proyecto para obtener la última versión de pago
2. la misma versión en otra carpeta
3. reemplazar la carpeta .svn de la nueva caja para la copia de trabajo (he reemplazado los archivos .svn-base)

Answer 13

1. Echa un vistazo a la carpeta con el archivo problemático desde el repositorio hasta otra ubicación.
2. Asegúrate de que .svn\text-base\<problematic file>.svn-base sea idéntico a uno desprotegido.
3. Asegúrese de que la sección del archivo problemático (todas las líneas de la sección) en .svn\entries es idéntica a una salida.

Answer 14

No vas a creer esto, pero en realidad me haya solucionado mi error mediante la eliminación de la postura <scm>...</scm> desde el archivo infractor pom.xml que estaba esperando a la llegada. Contenía la URL del repositorio de subversión se comprueba in (esto es lo que es la configuración Maven!), pero de alguna manera generó una suma de comprobación defectuosa para el archivo durante el check-in.

Probé literalmente todos los métodos antes mencionados para solucionar esto, pero fue en vano. ¿Encontré una situación muy rara en la que el generador de suma de comprobación no es lo suficientemente robusto?

Answer 15

También me encontré con este problema y estaba tratando de buscar soluciones rápidas, intenté algunas de las soluciones dadas en este hilo. Así es como he resuelto este problema en mi entorno de desarrollo (para mí fue un cambio mínimo):

1- directorio localmente eliminado en el que se corrompe el archivo (WEB-INF):

svn: Checksum mismatch for 'path-to-folder\WEB-INF\web.xml': 
    expected: d60cb051162e4a6790a3ea0c9ddfb434 
    actual: 16885ded2cbc1adc250e4cbbc1427546 

2 - copiar y pegar directorio (WEB-INF) a partir de una copia nueva

3- ¿Se svn, ahora Eclipse/TortoiseSVN comenzó a mostrar conflicto en este directorio

4- conflicto marcarse como resuelto

Esto funcionó, pude actualizar, cometer web.xml corrompido anteriormente

Answer 16

En mi caso, la suma fue diferente. Todo lo que he hecho fue:

1) Hacer cheque a nombre de carpeta separada

2) Sustituir por el archivo de esta carpeta en el directorio .svn con mi problema proyecto en archivos que se decía en el mensaje de error SVN-cliente

3) .. ¡Beneficio!

Answer 17

Como alternativa a la extracción de una copia nueva (que también tuve que hacer después de probar todas las otras opciones) y la fusión de todos los cambios guardados anteriormente, el siguiente enfoque funcionó de la misma manera, pero se guardó me una cantidad considerable de tiempo, y posiblemente algunos errores:

1. obtiene una copia de trabajo nueva
2. Copiar la carpeta .svn de usted copia nueva en su copia corrupta
3. Voila

Por supuesto, debe hacer una copia de seguridad de su copia de trabajo corrupta original por si acaso. En mi caso, tuve la libertad de eliminarlo cuando terminé, ya que todo salió bien.

Answer 18

1) Vaya a la carpeta que causa el problema 2) Ejecute el comando svn update --set-depth empty 3) Esta carpeta se vaciará y revertirá la carpeta vacía. 4) sincronizar con el svn y actualizar.

Esto funciona para mí.

Answer 19

Esto ocurrirá cuando la carpeta .svn esté dañada. Solución: Elimine toda la carpeta del archivo y vuelva a abrir la carpeta.

Answer 20

Aunque este es un problema antiguo, pensé que también daría mis 2 centavos, ya que solo he luchado con el problema durante más de una hora.

Las soluciones anteriores no me funcionaron o me parecieron demasiado complicadas.

Mi solución fue simplemente eliminar todas las carpetas svn del proyecto.

find . -name .svn -exec rm -rf {} \;

Después de esto, hice la caja sencilla de nuevo el proyecto. Dejé intactos todos mis archivos no comprometidos, pero aún obtuve una reconstrucción de todos los archivos svn.

Answer 21

he tenido este problema en Ubuntu 14.04 y resolverlo por pasos seguir:

1. $ cd/var/www/miProyecto
2. $ actualizar SVN
3. $ svn update

después de estos pasos, puedo enviar el archivo sin error.