Algunas veces, me metí en situaciones en las que uno de mis repositorios SVN se corrompió y pudimos hacer cualquier cosa con algunas versiones o ramas del proyecto sin saber realmente lo que hicimos. Entonces, ¿qué puede hacer que un repositorio se corrompa?¿Cómo se puede dañar un repositorio SVN?
Parece que las incompatibilidades entre los clientes pueden causar problemas, más específicamente con conjuntos de caracteres.
Básicamente, hay tres casos distintos:
El hardware defectuoso suele ser el más difícil de detectar, excepto en los casos más obvios. El caso 2 se puede evitar limitando el acceso de inicio de sesión al servidor. Todo lo demás es un error en Subversion. (Esto incluye problemas de compatibilidad entre el cliente y el servidor.) Debería nunca ser capaz de corromper el repositorio simplemente utilizando un cliente de Subversion (ni siquiera cuando hay un error en el cliente, IMO).
Estaría muy sorprendido de ver un error en Subversion. Se desarrolla con el objetivo de no perder una sola información debido a un error en una versión final. – Hardcoded
Estaría muy sorprendido si no hubiera un error en Subversion, al acecho en algún rincón oscuro. Cada pieza de software tiene una serie de errores potencialmente muy graves, la pregunta es en qué circunstancias se manifestará. – JesperE
Potencial corrupción del sistema de archivos o alguien molestando con los directorios svn internos?
Lo he tenido varias veces. SVN no parece funcionar bien si el cliente se va mientras el servidor tarda mucho tiempo en hacer ciertas cosas. No conozco los detalles exactos, pero hice unos pocos kill -9 en lo que pensé que eran procesos de solo lectura y terminé ejecutando un svnadmin cleanup posteriormente antes de que el servidor respondiera nuevamente.
No hay procesos de solo lectura en svn; siempre crea una transacción, incluso para la actualización. Ver http://svnbook.red-bean.com/en/1.0/ch05.html#svn-ch-5-sect-1.1 para más detalles. – CesarB
svnadmin no tiene un comando de limpieza. svn cleanup es un comando de cliente. En todos los casos, excepto en el archivo: /// acceso al repositorio, un bloqueo/cuelgue del cliente nunca puede dañar el servidor o los datos.Y el acceso al archivo: /// a través de la red no es una práctica recomendada. –
@Bert: Vaya, quise decir svnadmin recover. – flussence
Esto es bastante común en file:// repos basados, sin embargo, si tiene un único usuario/servicio accediendo al repositorio, esto no sucederá.
Siempre existe la posibilidad de que el hardware esté defectuoso. Las cosas como los errores de bits en la memoria pueden causar corrupción silenciosa en lugar de simplemente bloquear la computadora; si el proceso del servidor svn es el afectado, el repositorio puede dañarse.
Tuve una corrupción de repos que me llevó un tiempo darme cuenta. En el servidor, accidentalmente había cambiado el propietario del directorio .svn en el repositorio a un usuario no relacionado. SVN me dio errores de corrupción después de eso hasta que borré y recreé el repositorio. Incluso después de que lo corregí. huele la frente
Si los depósitos no están en el disco local servidores SVN, pero en NFS, pueden resultar dañados si están utilizando el formato de Berkeley DB. En svn 1.5, FSFS se convirtió en el predeterminado para los repositorios nuevos: es perfectamente feliz vivir en sistemas de archivos sin bloqueo, como NFS.
Usted no está utilizando el archivo: /// acceso a través de una red, o es usted? –
¿Qué OS/versión? –
Bastantes, estamos en un entorno muy heterogéneo. – Loki