La placa base de un servidor dedicado que estoy alquilando desde hace cinco años se estropeó y la placa base fue reemplazada por una nueva. La muy antigua distribución (Debian) no podía seguir el ritmo de todo el hardware nuevo en la placa base, así que decidí reinstalar una nueva distribución (Debian Wheezy) desde cero (incluso hacer una actualización fue un poco problemático dado que la antigua Debian no funcionaba). Por lo que sé, no reconozco el chipset Ethernet de la nueva placa base, así que lo reinstalé desde cero).
Reinstalé SVN y obtuve todos los repositorios haciendo lo siguiente:
tar -xzf repoBackups.tgz
Y funciona".
El problema es que aunque, digamos, Eclipse reconoce los repositorios SVN, quiere confirmar cada archivo, aunque sean idénticos.
¿Podría esto estar relacionado con las marcas de tiempo de los archivos? De cualquier manera, ¿tiene alguna idea de qué causó esto y cómo resolverlo?
IpodríaSimplemente pídales a todos que vuelvan a confirmar cada archivo de cada proyecto y creo que todo estaría bien, pero algunos de estos proyectos son bastante grandes y sería un poco doloroso para los desarrolladores.
Como pregunta adicional (y menos importante): ¿otro VCS como Git o Mercurial no "sufriría" este problema?
Respuesta1
Copiar los archivos de un repositorio de Subversion no es una forma compatible de realizar copias de seguridad. (Ver[SVN]: ¿Cómo hacer una copia de seguridad del repositorio?y¿Cuál es la mejor manera de hacer copias de seguridad de los repositorios de Subversion?y¿Cómo hago una copia de seguridad de un repositorio SVN remoto?para obtener métodos adecuados). Parece que la base de datos ha terminado en un estado corrupto.
Intente ejecutarlo svnadmin dumpen el repositorio no comprimido y svnadmin loaden el volcado resultante. Esto puede dar como resultado un repositorio que funcione (pero no hay promesas, no estoy muy familiarizado con svn).
Las marcas de tiempo de los archivos son irrelevantes. Subversion no los usa para decidir si confirmar, usa números de revisión.