tortoise tag from create svn subclipse

from - tag svn



Reparar suma de comprobación SVN (21)

  1. Echa un vistazo a la carpeta con el archivo problemático desde el repositorio hasta otra ubicación.
  2. Asegúrese 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 sea ​​idéntica a una sección desprotegida.

Estoy usando subclipse en Flex Builder 3, y recientemente recibí este error cuando intento comprometer:

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

Trabajé alrededor de esto por:

  1. Comprometer todos los otros archivos modificados, omitiendo el problemático.
  2. Copia del contenido del archivo de problema a una ventana de TextMate
  3. Eliminar mi proyecto en FlexBuilder / Eclipse
  4. Comprobando mi proyecto recién salido de SVN
  5. Copiando el texto del archivo de problema nuevamente desde la ventana de TextMate
  6. Cometer 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?

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) sincronización con el svn y actualización.

Este trabajo para mí.

Aunque este es un tema viejo, pensé que yo también daría mis 2 centavos, ya que he luchado con el problema por 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 el pago simple del proyecto nuevamente. Dejé intactos todos mis archivos no comprometidos, pero aún obtuve una reconstrucción de todos los archivos svn.

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

  1. Vea una nueva copia de trabajo
  2. Copie la carpeta .svn de su 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.

El archivo en el directorio .svn que realiza un seguimiento de lo que ha desprotegido, 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 normal de archivos impares, y puede ser debido a varios problemas, como un programa de subversión que se muere a mitad de camino, interrupción de energía, etc.

A menos que ocurra más, no sacaré mucho provecho de eso.

Se puede arreglar haciendo lo que hizo, haga una copia de sus archivos de trabajo, revise una copia nueva y vuelva a agregar los archivos modificados.

Tenga en cuenta que esto podría causar problemas si tiene un proyecto ocupado en el que normalmente debería fusionarse en los 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 proceso de pago y luego la subversión perderá la pista de cómo deberían fusionarse sus cambios.

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

Sin embargo, si realiza un pago final nuevo, complete con los cambios de sus colegas, ahora parece que eliminó sus cambios y los sustituyó por los suyos. Sin conflictos y sin indicaciones de subversión de que algo anda mal.

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

1) Hacer Check Out en una carpeta separada

2) Reemplazar 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 svn-client

3) .. ¡Beneficio!

Esto sucederá cuando la carpeta .svn esté corrupta. Solución: elimine toda la carpeta del archivo y vuelva a abrir la carpeta.

He observado una gran cantidad de soluciones desde parches .svn / archivo de entradas 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

Justo hoy, logré recuperarme de este error comprobando una copia del directorio dañado en / tmp y reemplazando los archivos en .svn / text-base con los que acabo de usar. Escribí el procedimiento en 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.

No creerá esto, pero en realidad he solucionado mi error eliminando la <scm>...</scm> del archivo pom.xml ofensivo que esperaba verificar. Contenía la URL del repositorio de subversión está registrado (¡esto es lo que la configuración de Maven es para!), pero de alguna manera generó una suma de comprobación defectuosa para el archivo durante el registro.

Literalmente probé todos los métodos antes mencionados de arreglar 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?

Ocasionalmente obtengo cosas similares, generalmente con archivos 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 con el problema y ejecutar

svn update

para recrearlo

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

En términos generales, diría que es una buena idea no dejar los archivos editados sin confirmar y mantener la copia de trabajo ordenada; 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.

Otra forma más fácil ...

  1. Actualiza tu proyecto para obtener la última versión
  2. pagar la misma versión en otra carpeta
  3. reemplace la carpeta .svn del nuevo proceso de pago por la copia de trabajo (he reemplazado archivos .svn-base)

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

CAVEAT: ¡ Asegúrate de que tu copia local sea la versión más conocida, y que cualquier otra persona en tu proyecto sepa lo que estás 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 para eliminación directa:

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

¡buena suerte!

J

SVN mantiene copias prístinas de todos los archivos que compras 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 alterado se modificó de alguna manera. Qué significa eso?

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

Todos 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. Error 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 de # 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 de base de datos, no el archivo real que estaba tratando de comprometer.

Si tuviéramos este problema, nuestras máquinas virtuales de desarrollo son todas * nix nuestras estaciones de trabajo win32. algunos tontos crearon archivos del mismo nombre (caso diferente) en el recuadro * nix, de repente, los checkouts en Win32 explotaron ... porque win no sabe cuál de los 2 archivos del mismo nombre para MD5 contra , las cajas de * nix estaban bien ... dejándonos rascarnos la cabeza un poco

Pude actualizar el repositorio en el cuadro de victoria copiando las carpetas ".svn" de un cuadro * nix con una buena copia de trabajo. Todavía tenemos que ver si el repositorio se puede limpiar hasta el punto en que podamos hacer un pago completo de nuevo

También hay una causa más simple para esto que simplemente 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 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.

También tropecé con este problema y estaba tratando de buscar soluciones rápidas, intenté 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 el archivo se corrompió (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 nueva compra

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

4- Conflicto marcado como resuelto

Esto funcionó, pude actualizar, comprometer web.xml dañado anteriormente

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

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

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

así es como solucioné el problema: v simple, pero según jsh anterior, necesito estar seguro de que tu copia es la mejor.

simplemente

  1. haga una copia de todos los archivos problemáticos, en la misma carpeta.
  2. borra los viejos con svn rm
  3. cometer.
  4. a continuación, cambie el nombre de las copias a los nombres de archivo originales.
  5. cometer nuevamente.

sospecho que esto probablemente mata todo tipo de historial de revisiones en ese archivo, así que es una forma bastante fea de hacerlo ...

try: svn up --force file.c

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