Reparar la suma de comprobación SVN

StackOverflow https://stackoverflow.com/questions/6130

  •  08-06-2019
  •  | 
  •  

Pregunta

Estoy usando subclipse en Flex Builder 3 y recientemente recibí este error al intentar confirmar:

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

Lo solucioné mediante:

  1. Confirmando todos los demás archivos modificados, omitiendo el problemático.
  2. Copiar el contenido del archivo de problemas a una ventana de TextMate
  3. Eliminar mi proyecto en FlexBuilder/Eclipse
  4. Comprobando mi proyecto recién salido de SVN
  5. Copiar el texto del archivo del problema nuevamente desde la ventana TextMate
  6. Confirmar los cambios.

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

Quizás lo más importante sea: ¿es esto un síntoma de un problema mayor?

¿Fue útil?

Solución

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

Esto no es más peligroso o crítico que el problema normal de un archivo extraño y puede deberse a varios problemas, como un programa de subversión que muere durante un cambio, una interrupción del suministro eléctrico, etc.

A menos que suceda más, no sacaría mucho provecho de ello.

Se puede solucionar haciendo lo que hizo: hacer una copia de sus archivos de trabajo, retirar una copia nueva y volver a agregar los archivos modificados.

Tenga en cuenta que esto podría causar problemas si tiene un proyecto ocupado en el que normalmente tendría que fusionar los cambios.

Por ejemplo, usted y un colega obtienen una copia nueva y comienzan a trabajar en el mismo archivo.En algún momento, su colega verifica sus modificaciones.Cuando intentas hacer lo mismo, obtienes el problema de suma de comprobación que tienes.Si ahora hace copias de sus archivos modificados, realice una nueva verificación, entonces subversion perderá la pista de cómo se deben fusionar nuevamente sus cambios.

Si no tuvo el problema en este caso, cuando pueda registrar sus modificaciones, primero necesitará actualizar su copia de trabajo y posiblemente manejar un conflicto con su archivo.

Sin embargo, si realiza una revisión nueva, completa con los cambios de su colega, ahora parecerá que eliminó sus cambios y los sustituyó por los suyos propios.Sin conflictos y sin indicios de subversión de que algo anda mal.

Otros consejos

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 para que esto suceda es cuando alguien escribe un reemplazo de texto recursivo en la copia de trabajo, sin excluir los archivos .svn.
Esto significa que las copias originales de los archivos (básicamente la versión BASE de los archivos, que se almacena dentro del área administrativa .svn) se modifican y eso invalida la suma MD5.

@Andrew Hedges:eso también explica por qué su solución soluciona este problema.

SVN mantiene copias impecables de todos los archivos que extrae enterrados en los directorios .svn.Esto se llama base de texto.Esto permite diferencias y reversiones rápidas.Durante varias operaciones, SVN realizará sumas de verificación en estos archivos de base de texto para detectar problemas de corrupción de archivos.

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

  1. Corrupción del disco (HDD o cable IDE defectuoso)
  2. Mala RAM
  3. Mal enlace de red
  4. Algún tipo de proceso en segundo plano alteró un archivo a tus espaldas (malware)

Todo esto es malo.

SIN EMBARGO, Creo que tu problema es diferente.Mira el mensaje de error.Tenga en cuenta que esperaba algunos hashes MD5, pero en su lugar obtuvo "nulo".Si se tratara de un simple problema de corrupción de archivos, esperaría que tuviera dos hashes MD5 diferentes para lo esperado/obtenido.El hecho de que tenga un "nulo" implica que algo más está mal.

Tengo dos teorías:

  1. Error en SVN.
  2. Algo tenía un bloqueo exclusivo en el archivo y el MD5 no pudo funcionar.

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

En el caso número 2, verifique si hay algo que tenga el archivo bloqueado.Puede descargar una copia de Process Explorer para comprobarlo.Tenga en cuenta que probablemente desee ver quién tiene un candado en el base de texto archivo, no el archivo real que estaba intentando confirmar.

De vez en cuando recibo cosas similares, generalmente con archivos a los que nadie ha estado cerca en semanas.Generalmente, si sabe que no ha estado trabajando en el directorio en cuestión, puede simplemente eliminar el directorio que tiene el problema y ejecutar 

svn update

para recrearlo.

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

En términos generales, diría que es una buena idea no dejar archivos editados sin confirmar y mantener la copia de trabajo ordenada; no agregue un montón de archivos adicionales a la copia de trabajo que no vaya a utilizar.Confirme regularmente, y luego, si la copia de trabajo falla, puede simplemente eliminarlo todo y comenzar de nuevo sin preocuparse por lo que podría perder o no, y sin la molestia de tratar de averiguar qué archivos guardar.

Hoy mismo, logré recuperarme de este error revisando una copia del directorio dañado en /tmp y reemplazando los archivos en .svn/text-base con los recién combinados.Escribí el procedimiento con cierto detalle. aquí en mi blog. Me interesaría saber de usuarios de SVN más experimentados cuáles son las ventajas y desventajas de cada enfoque.

intentar:svn arriba --force archivo.c

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

He observado muchas soluciones, desde parchear el archivo .svn/entries hasta realizar un nuevo pago.

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

Matt, hay una manera más fácil de la que describiste: modificar la suma de verificación en el archivo .svn/entries.Aquí está la descripción completa:http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

Otra solución alternativa, posiblemente incluso más aterradora, para los conflictos de suma de comprobación que encontré es la siguiente:

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

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 para eliminación directa:

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

¡buena suerte!

j

Como alternativa a revisar una copia nueva (lo que también tuve que hacer después de probar todas las demás opciones) y luego fusionar todos los cambios que guardó previamente, el siguiente enfoque funcionó de la misma manera, pero me ahorró una cantidad considerable. de tiempo, y posiblemente algunos errores:

  1. Consulte una copia de trabajo nueva
  2. Copie la carpeta .svn de su copia nueva a su copia corrupta
  3. Voilá

Por supuesto, debes hacer una copia de seguridad de tu copia de trabajo original corrupta por si acaso.En mi caso, pude eliminarlo una vez terminado, ya que todo salió bien.

Esto sucederá cuando la carpeta .svn esté dañada.Solución:Elimine toda la carpeta que contiene el archivo y vuelva a verificar la carpeta.

Si tuviera este problema, todas nuestras máquinas virtuales de desarrollo son *nix y nuestras estaciones de trabajo son win32.Algunos tontos crearon archivos del mismo nombre (caso diferente) en el cuadro *nix de repente de repente en Win32 explotan ...Porque Win no sabe cuáles de los 2 archivos del mismo nombre para MD5, los chocos en *nix estaban bien ...dejándonos rascarnos la cabeza un rato

Pude actualizar el repositorio en el cuadro Win copiando las carpetas ".svn" desde un cuadro *nix con una buena copia funcional.Todavía tenemos que ver si el repositorio se puede limpiar hasta el punto en que podamos realizar un pago completo nuevamente.

Otra manera fácil....

  1. Actualice su proyecto para obtener la última versión
  2. comprar la misma versión en otra carpeta
  3. reemplace la carpeta .svn de la nueva compra a la copia de trabajo (he reemplazado los archivos .svn-base)
  1. Retire solo la carpeta con el archivo problemático del repositorio a otra ubicación.
  2. Cerciorarse .svn\text-base\<problematic file>.svn-base es idéntico a uno retirado.
  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éntico a uno retirado.

No lo creerás, pero en realidad solucioné mi error eliminando el <scm>...</scm> postura del archivo pom.xml ofensivo que esperaba registrar.Contenía la URL del repositorio de Subversion en el que está registrado (¡para eso está la configuración de Maven!), pero de alguna manera generó una suma de verificación defectuosa para el archivo mientras se registraba.

Literalmente probé todos los métodos antes mencionados para solucionar este problema, pero fue en vano.¿Me encontré con una situación muy rara en la que el generador de suma de comprobación no es lo suficientemente robusto?

También me topé con este problema y estaba tratando de buscar soluciones rápidas, probé algunas de las soluciones que se ofrecen en este hilo.Así es como resolví este problema en mi entorno de desarrollo (para mí fue un cambio mínimo):

1- Directorio eliminado localmente en el que se corrompió el archivo (WEB-INF):

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

2- Directorio copiado y pegado (WEB-INF) de una compra nueva

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

4- Conflicto marcado como resuelto

Esto funcionó, pude actualizar y confirmar el archivo web.xml dañado anteriormente.

En mi caso la suma fue diferente.Todo lo que hice fue:

1) Realice el pago en una carpeta separada

2) Reemplace por archivo de esta carpeta en el directorio .svn con el archivo de problema de mi proyecto que se dijo en el mensaje de error de svn-client

3) ...¡Beneficio!

Aunque este es un problema antiguo, pensé en dar mi granito de arena también, ya que acabo de luchar 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, volví a realizar una verificación simple del proyecto.Por lo tanto, dejé intactos todos mis archivos no confirmados, pero aún así obtuve una reconstrucción de todos los archivos svn.

Tuve este problema en ubuntu 14.04 y lo resolví siguiendo los pasos:

  1. $ cd /var/www/miProyecto
  2. $svn actualización
  3. actualización $ svn

Después de estos pasos pude enviar el archivo sin errores.

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

Esto funciona para mí.

Así es como solucioné el problema: muy simple, pero según jsh anterior, debes asegurarte de que tu copia sea la mejor.

simplemente

  1. haga una copia de todos los archivos problemáticos, en la misma carpeta.
  2. borra los antiguos con svn rm
  3. comprometerse.
  4. luego cambie el nombre de las copias a los nombres de archivo originales.
  5. comprometerse de nuevo.

Sospecho que esto probablemente elimine todo tipo de historial de revisiones en ese archivo, por lo que es una forma bastante fea de hacerlo...

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top