¿Cómo se puede dañar un repository SVN?

Unas cuantas veces ya, me metí en situaciones en las que uno de mis repositorys SVN se corrompió y pudimos hacer cualquier cosa con algunas versiones o twigs del proyecto sin saber realmente lo que hicimos. Entonces, ¿qué puede hacer que un repository se corrompa?


Parece que las incompatibilidades entre los clientes pueden causar problemas, más específicamente con sets de caracteres.

Básicamente hay tres casos distintos:

  1. Hardware defectuoso (memory, corrupción fs, etc.)
  2. Los usuarios con acceso de inicio de session al server pueden dañar los files del repository.
  3. Errores en Subversion.

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 session al server. Todo lo demás es un error en Subversion. (Esto incluye problemas de compatibilidad entre el cliente y el server.) Nunca se debe poder dañar el repository simplemente mediante el uso de un cliente de Subversion (ni siquiera cuando haya un error en el cliente, IMO).

¿Corrupción potencial del sistema de files o alguien molestando con los directorys svn internos?

Siempre existe la posibilidad de que el hardware esté defectuoso. Las cosas como los errores de bits en la memory pueden causar corrupción silenciosa en lugar de simplemente bloquear la computadora; si el process del server svn es el afectado, el repository puede dañarse.

Si los repositorys no están en el disco local de los serveres svn, sino en NFS, pueden corromperse si están usando el formatting berkley db. En svn 1.5, FSFS se convirtió en el pnetworkingeterminado para los repositorys nuevos: es perfectamente feliz vivir en filesystems sin locking, como NFS.

Lo he tenido varias veces. SVN no parece funcionar bien si el cliente se va mientras el server tarda mucho time en hacer ciertas cosas. No conozco los detalles exactos, pero he realizado algunos kill -9 s en lo que pensé que eran processs de solo lectura y terminé teniendo que ejecutar una svnadmin cleanup después antes de que el server respondiera nuevamente.

Tuve una corrupción repo que me tomó un time averiguar. En el server, accidentalmente había cambiado el propietario del directory .svn en el repository a un usuario no relacionado. SVN me dio errores de corrupción después de eso hasta que borré y recreé el repository. Incluso después de que lo corregí. golpea la frente

Esto es bastante común en los repositorys de file:// , sin embargo, si tiene un solo usuario / service accediendo al repository, esto no sucederá.

    Intereting Posts